> 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
