Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel

["Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>]

Le 22/05/2011 08:34, Eric W. Biederman a écrit :
> Jiri Pirko<jpirko@redhat.com>  writes:
>
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>> And because some setups may still require the skb not to be untagged,
>>> may be we need the ability to re-tag the skb in some situations...
>>> When a protocol handler or rx_handler is explicitly registered on a
>>> net_device which expect to receive tagged skb, we should deliver
>>> tagged skb to it... Arguably, this may sound incredible for the
>>> general case, but may be required for not-so-special cases like
>>> bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>
> tcpdump on the non-vlan interface for one.

bridge is another. More precisely, there is a difference between the following two setups:

1/ eth0 - eth0.100 - br0 - eth1.200 - eth1

2/ eth0 - br0 - eth1

In case 1, it is normal and desirable for the bridge to see untagged skb.

In case 2, it is desirable for the bridge to see untouched (possibly tagged) skb. If current bridge 
implementation is able to handle skb from which we removed a tag, in this situation, it means that 
bridge currently "fix improper untagging" by itself, by forcing re-tagging on output. I think is 
should not be the job of protocol handlers to fix this. Again, a generic feature should to it when 
necessary.

Think of the following setups:

3/ eth0 - br0 - eth1.200 - eth1.
4/ eth0 - eth0.100 - br0 - eth1

What if one expect this setup to add (3) or remove (4) one level of vlan nesting? This is precisely 
what this setup suggest. How can we instruct the bridge to do so? It is not the bridge 
responsibility to do any vlan processing. bridge is expected to... bridge !

	Nicolas.