Re: [PATCH v5] af_packet: Handle outgoing VLAN packets without hardware offloading

[Willem de Bruijn]

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