Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR

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

Le 24/05/2011 06:20, Ben Greear a écrit :
<snip>

> Then I think we should put it back with pf_packet logic. Possibly with
> a per-socket option to disable this and send it as only aux data if that
> is more efficient.

Why would we need a per-socket option for that?

If the socket listen on eth0, it probably expect to receive the raw packet. If it happens to expect 
the untagged packet, it should listen on vlan2000.

The only reason I can imagine to listen on eth0 while expecting the packet to be untagged is to 
listen to several VLAN at the same time on a single socket, while still expecting the kernel or the 
NIC to extract the vlan ID for us. But I don't have a real life use case for this in mind.

And maybe, for that particular situation, we should have a special vlan interface, with wildcard 
vlan ID:

        +--eth0.100
        |
eth0 --+--eth0.200
        |
        +--eth0.any

- Someone listening on eth0 would receive raw packet.
- Someone listening on eth0.100/eth0.200 would receive untagged packets originally having 100/200 as 
the VLAN ID.
- Someone listening on eth0.any would receive untagged packets originally having any VLAN ID and 
would not receive non-originally-tagged packets.

> If it turns out the NIC is not stripping VLAN tags for whatever reason,
> we might be able to optimize things so that it never does the HW emulation
> so that it never has to un-do it later.

It might be very tricky to avoid any do-undo-redo situation. I will latter try and describe all the 
possible situations: with/without hw-accel, with/without a protocol handler registered on the parent 
interface, with/without a child interface build on top of a particular parent interface and with the 
corresponding VLAN ID...

	Nicolas.