On Sun, 9 Dec 2001, Henrik Nordstrom wrote: > On Sunday 09 December 2001 16.01, jamal wrote: > > Henrik, > > Can you please try the attahed patch against iproute2-2.4.7-now-ss010824? > > Seems to make the tc userspace program to properly reject the arguments. > That was the intent; allowing it was harmless but gives a bad impression of functionality. So i guess we could say the patch works. > > 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. > > 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 ;-> > but then the netfilter > queueing seems to be very simplistic only supporting one queue per protocol > family and this queueing interface is already used for queueing packets to > userspace, so perhaps not as easy as I thought.. > [..] No, implementation is a non-issue. There is no need for it. 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. cheers, jamal
