Subject: Re: [RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies

From: Patrick McHardy <[email-masked]>
Date: Wed, 09 Jul 2008 00:30:04 +0200

David Miller wrote:
> From: Patrick McHardy <[email-masked]>
> Date: Tue, 08 Jul 2008 12:14:51 +0200
>>
>> - packet socket auxdata is only available for non-mmaped sockets.
>>    For mmaped sockets the only place to store the data is in
>>    struct tpacket_hdr, but that would break compatibility. Not sure
>>    what to do about this case.
>>     
> The mmap socket limitation is pretty serious.  It's the only
> thing holding me back from just applying these patches right now.
>
> I think we should make a new version of the tpacket_hdr structure
> anyways, in order to make it more compat-friendly.  It currently
> has "unsigned long" members and other crap.
>
> We can design this thing to be extensible quite easily, by simply
> giving it an "offset" field.  My suggestion is:
>
> 1) sed 's/tpacket_hdr/tpacket_hdr_old/'
>
> 2) Create packet socket option PACKET_NEW_TPHDR which enables
>    use of a new tpacket_hdr layout.
>
> 3) Make new tpacket_hdr which has the VLAN tag stuff as well
>    as an 'offset' field so that we can add more stuff later
>    in a backwards compat way.
>
> 4) New new tpacket_hdr layout when PACKET_NEW_TPHDR has been
>    set.

That sounds good. Userspace needs to know about the size of
the tpacket_hdr before setting the ring parameters so it can
size the ring frames appropriately for the largest packet size
it wants to receive. This means the offset field in the
tpacket_hdr is redundant, so I'll just add a getsockopt
option for getting the size. Unless we want to be able to
include only a partial tpacket_hdr, but I don't think that
would be very useful.