Re: [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages

[Martin Devera <devik@cdi.cz>]

> True, but not all applications of shaping have the luxury of egress. For 
> example, consider the not too uncommon example of a computer connected via 
> 100Mbps networking to a DSL modem, and you want to tune the use of the link 
> without needing to introduce a router inbetween.
> 
> > The implementation/extension is trivial. There is no need for it; I went
> > at great lengths with Martin/devik on this  Maybe he can help me here ;->
> 
> So do you have any argument why one should not be able to shape incoming 
> local traffic to a station in a good manner without having a router do the 
> shaping?

jamal would probably say here that it is nonsence to delay/queue packet
which already arived to your box :)
I still think that is COULD be helpful and much more clear
to be able to attach any qdisc at ingres.

Current "ingres" qdisc could remain and work in the same way but
additionaly when qdisc returns OK - I eat the packet - then net_bh
would try to dequeue it.
Then there would be no "special" qdisc like ingres - it would
be subset of regular qdisc.

The only real (implementation) problem I see is related to
netif_restart - we'd need rather tc subsys suplied callback
sch_restart(sch) which would do different thing for ingres
and egres. All other parts should be easy to implement.

On other note. I created so called IMQ device which solves
different (but similar) problem. It should be easy to extend
it to queue all incoming packets here too. Now only all 
outgoing ones go here.
IMQ is pretty simple device and is already used in production
environment by two people.

devik


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/