This adds some parsing overhead in the datapath. SOCK_RAW does not need it, as it can see the whole VLAN tag. Perhaps limit the new branches to SOCK_DGRAM cases? Then the above can also be simplified.
I considered this approach before, but it would result in different metadata for SOCK_DGRAM and SOCK_RAW scenarios. This difference makes me hesitate because it might be better to provide consistent metadata to describe the same packet, regardless of the receiver's approach. These are just my thoughts and I'm open to further discussion.
FWIW, I vote for Willem's approach here: there is no problem with having different metadata in SOCK_DGRAM and SOCK_RAW, as the underlying parsing efforts are different anyway, along with the start offset for BPF. (No, I'm not super happy to see BPF code reaching out to offset -4096 or so to get VLAN as metadata. That just smells like a horrendous kludge.) To me, it makes plenty of sense to have:
- SOCK_DGRAM for compatibility (used by everyone today), doing all historical
shenanigans with VLANs and metadata
- SOCK_RAW for a modern, new API, making no assumption on encapsulation, and
presenting an untouched linear frame
- yes this means different BPF code for the same filter between the two modes
Again, my .02c
Thanks for chiming in. Generally agreed.
We cannot modify established SOCK_RAW behavior in arbitrary ways either. But there are already two forms in which VLAN data may arrive. And with SOCK_RAW in-band VLAN tags can be parsed as is.
(fyi, your message was dropped by the list's plaintext filter)