[LARTC] QoS on receive

[LARTC] QoS on receive

[Alexander Sirotkin]

It appears that while Linux has plenty of traffic shaping mechanism on 
transmit, there is nothing on receive side.
While generally it does make sense since transmit is more CPU intensive 
operation, after all receive also
consumes CPU cycles. It is clear that it's best to drop the packet as 
soon as possible, i.e. on receive, if possible -
by the driver itself. It may not be feasible in general case, but I can 
think of a couple of scenarios when it does
make sense.

Any ideas ?
Maybe there is some similar QoS mechanism that I'm not aware of ?

-- 
Alexander Sirotkin
SW Engineer

Texas Instruments
Broadband Communications Israel (BCIL)
Tel:  +972-9-9706587
________________________________________________________________________
"Those who do not understand Unix are condemned to reinvent it, poorly."
      -- Henry Spencer 

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS on receive

[pramod]

Dropping of packets on the receive side can be done bu IPTABLES..

thanks
 pramod

Alexander Sirotkin wrote:

> It appears that while Linux has plenty of traffic shaping mechanism on 
> transmit, there is nothing on receive side.
> While generally it does make sense since transmit is more CPU 
> intensive operation, after all receive also
> consumes CPU cycles. It is clear that it's best to drop the packet as 
> soon as possible, i.e. on receive, if possible -
> by the driver itself. It may not be feasible in general case, but I 
> can think of a couple of scenarios when it does
> make sense.
>
> Any ideas ?
> Maybe there is some similar QoS mechanism that I'm not aware of ?
>

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] QoS on receive

[Andy Furniss]

Alexander Sirotkin wrote:
> It appears that while Linux has plenty of traffic shaping mechanism on 
> transmit, there is nothing on receive side.
> While generally it does make sense since transmit is more CPU intensive 
> operation, after all receive also
> consumes CPU cycles. It is clear that it's best to drop the packet as 
> soon as possible, i.e. on receive, if possible -
> by the driver itself. It may not be feasible in general case, but I can 
> think of a couple of scenarios when it does
> make sense.
> 
> Any ideas ?
> Maybe there is some similar QoS mechanism that I'm not aware of ?
> 

Yes it's called ingress policing there is mention in LARTC and it is 
possible to do quite complicated things with it. See the diffserv 
examples in iproute2.

Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc