> > > 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)
