Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic skb handler

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Mon, 27 Apr 2020 13:52:54 -0700 Jakub Kicinski wrote:
>> On Mon, 27 Apr 2020 14:42:08 -0600 Jason A. Donenfeld wrote:
>> > A user reported that packets from wireguard were possibly ignored by XDP
>> > [1]. Apparently, the generic skb xdp handler path seems to assume that
>> > packets will always have an ethernet header, which really isn't always
>> > the case for layer 3 packets, which are produced by multiple drivers.
>> > This patch fixes the oversight. If the mac_len is 0, then we assume
>> > that it's a layer 3 packet, and in that case prepend a pseudo ethhdr to
>> > the packet whose h_proto is copied from skb->protocol, which will have
>> > the appropriate v4 or v6 ethertype. This allows us to keep XDP programs'
>> > assumption correct about packets always having that ethernet header, so
>> > that existing code doesn't break, while still allowing layer 3 devices
>> > to use the generic XDP handler.
>> 
>> Is this going to work correctly with XDP_TX? presumably wireguard
>> doesn't want the ethernet L2 on egress, either? And what about
>> redirects?
>> 
>> I'm not sure we can paper over the L2 differences between interfaces.
>> Isn't user supposed to know what interface the program is attached to?
>> I believe that's the case for cls_bpf ingress, right?
>
> In general we should also ask ourselves if supporting XDPgeneric on
> software interfaces isn't just pointless code bloat, and it wouldn't
> be better to let XDP remain clearly tied to the in-driver native use
> case.

I was mostly ignoring generic XDP for a long time for this reason. But
it seems to me that people find generic XDP quite useful, so I'm no
longer so sure this is the right thing to do...

-Toke