Received-SPF: pass (google.com: domain of linux-kernel+bounces-203096-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240604054823.20649-1-chengen.du@canonical.com>
 <665f9bccaa91c_2bf7de294f4@willemb.c.googlers.com.notmuch>
 <CAPza5qctPn_yrFQrO_2NHXpz-kf1qTwxk_APn2t5VU30sY=-MQ@mail.gmail.com> <6df76928-be7f-483e-9685-88ee245ef1bf@orange.com>
In-Reply-To: <6df76928-be7f-483e-9685-88ee245ef1bf@orange.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 5 Jun 2024 15:22:52 -0400
Message-ID: <CAF=yD-LmCyF2pobgX0nDe0=iEBsXc90Nqe=By2nAqFZd=nL82g@mail.gmail.com>
Subject: Re: [PATCH v5] af_packet: Handle outgoing VLAN packets without
 hardware offloading
To: alexandre.ferrieux@orange.com
Cc: Chengen Du <chengen.du@canonical.com>, davem@davemloft.net, edumazet@google.com, 
	kuba@kernel.org, pabeni@redhat.com, kaber@trash.net, 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

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