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

[alexandre . ferrieux]

On 05/06/2024 08:03, Chengen Du wrote:
> On Wed, Jun 5, 2024 at 6:57 AM Willem de Bruijn
> <willemdebruijn.kernel@xxxxxxxxx> wrote:
> >
> > 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

-Alex

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.