* Patrick McHardy [off-list ref] 2006-06-27 00:29

Doesn't sound too silly (actually quite nifty in my opinion),
but I'm not sure I understand correctly, binding to ifb doesn't
work since it changes both skb->dev and skb->input_dev.

I don't understand this concern. So far the mirred action
updates iif but that can be made configurable.

* Patrick McHardy [off-list ref] 2006-06-27 00:49

Small clarification: with queueing at ingress I mean queueing after
the bottleneck. It might work if you introduce a virtual bottleneck,
but in that case in my experience the bandwidth limit you have to use
is dependant on the number of TCP flows, so usually you can't specify
a limit that will always work, and its wasteful if there is a smaller
number of TCP flows. The reason why you would do it, limiting or
prioritizing incoming traffic on the _real_ bottleneck, is not
achievable of course. Also noteworthy is that policers don't behave
any better, and any other schemes I've tried (I also experienced a
lot of with TCP rate control) have similar or related problems.

My interest in ingress queueing is mainly on a local delivery
case where skb->tstamp can be modified to control tcp metrics.
I agree that a lot of wrong expectations have developed with
IMQ and similiar devices.