> > It is a bit sad that one cannot queue packets in ingress. Would be quite > > useful to make ingress shaping behave more sane than what can be acheived > > with the queueless filter police mechanism. > > > > Look at the definition of work vs non-work conserving; This is design > intent. If you look at the datapath, it is totaly meaningless to put > queues at ingress, for routing when they are being queued on ingress as > well. hehe, jamal did you remember long discussion we have had about this (at diffserv list) ? :-) > > netfilter supports queueing/delaying of packets and then resume processing > > them at a later time using nf_reinject, so I think it should be possible to > > implement a ingress queue without too much effort.. > > 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 ;-> yup I have not read whole message first :) So that you remember. The conclusion was that only reason of queue at ingres might be fact that existing queue stays here as indicator of flow's activity. Definitely it would be helpful to create work conserving model of CBQ (HTB :-)) which would drop packets instead to dequeue them. IMHO ingres queuing could be used as poor man's way how to reshape (or priorize) traffic which can't be shaped at egress side (usualy because of adminstrative boundaries). This need would vanish in presence of such classfull work conserving CBQ. Note that you can do some similar things with policers but you can't do the same thinks as with CBQ - you can't set priorized borrowing hierarchy up. > For 2.5 we might be able to have the ipqueue code use the power of TC. it > already talks netlink; i'll talk to some of the netfilter people. ipqueue > has some speacial need to grab packets; we provide much more sophisticated > mechanisms than Netfilter; so maybe there's a marriage possibility. ipqueue !? what is it ? sounds good :) regards, devik
