* Patrick McHardy <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
