Subject: Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

From: Thomas Graf <[email-masked]>
Date: Tue, 27 Jun 2006 12:03:09 +0200

* Patrick McHardy <[email-masked]> 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-masked]> 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.