Message-ID: <CAHmME9pq8iFfuf2EZG_4xQhDekP+hZR8yUDgYEf3gWNONM_3Ew@mail.gmail.com>
Date:   Sat, 15 Aug 2020 09:54:56 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     David Miller <davem@...emloft.net>
Cc:     Jakub Kicinski <kuba@...nel.org>, Netdev <netdev@...r.kernel.org>,
        Thomas Ptacek <thomas@...kpuppet.org>,
        Adhipati Blambangan <adhipati@...a.io>,
        David Ahern <dsahern@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH net v4] net: xdp: account for layer 3 packets in generic
 skb handler

On Fri, Aug 14, 2020 at 11:27 PM David Miller <davem@...emloft.net> wrote:
>
> From: "Jason A. Donenfeld" <Jason@...c4.com>
> Date: Fri, 14 Aug 2020 23:04:56 +0200
>
> > What? No. It comes up repeatedly because people want to reuse their
> > XDP processing logic with layer 3 devices.
>
> XDP is a layer 2 packet processing technology.  It assumes an L2
> ethernet and/or VLAN header is going to be there.
>
> Putting a pretend ethernet header there doesn't really change that.

Actually, I wasn't aware that XDP was explicitly limited to L2-only,
as some kind of fundamental thing. A while back when this patchset
first came up, I initially posted something that gave unmodified L3
frames to XDP programs in the generic handler, but commenters pointed
out that this loses the skb->protocol changing capability, which could
be useful (e.g. some kind of custom v4->v6 modifying code), and adding
the pretend ethernet header would allow people to keep the same
programs for the L2 case as for the L3 case, which seemed *extremely*
compelling to me. Hence, this patch series has gone in the pretend
ethernet header direction.

But, anyway, as I said, I wasn't aware that XDP was explicitly limited
to L2-only, as some kind of fundamental thing. This actually surprises
me. I always thought the original motivation of XDP was that it
allowed putting a lot of steering and modification logic into the
network card hardware, for fancy new cards that support eBPF. Later,
the generic handler got added on so people could reuse those programs
in heterogeneous environments, where some cards have hardware support
and others do not. That seemed like a good idea to me. Extending that
a step further for layer 3 devices seems like a logical next step, in
the sense that if that step is invalid, surely the previous one of
adding the generic handler must be invalid too? At least that's my
impression of the historical evolution of this; I'm confident you know
much better than I do.

It makes me wonder, though, what will you say when hardware comes out
that has layer 3 semantics and a thirst for eBPF? Also deny that
hardware of XDP, because "XDP is a layer 2 packet processing
technology"? I know what you'll say now: "we don't design our
networking stack around hypothetical hardware, so why even bring it
up? I won't entertain that." But nevertheless, contemplating those
hypotheticals might be a good exercise for seeing how committed you
are to the XDP=L2-only assertion. For example, maybe there are
fundamental L2 semantics that XDP needs, and can't be emulated with my
pretend ethernet header -- like if you really are relying on the MACs
for something I'm not aware of; were that the case, it'd be compelling
to me. But if it's a bit weaker, in the form of, "we just don't want
to try anything with L3 at all because," then I admit I'm still a bit
mystified.

Nevertheless, at the risk of irritating you further, I will willingly
drop this patchset at your request, even though I don't completely
understand the entire scope of reasoning for doing so. (For posterity,
I just posted a v6, which splits out that other bug fix into something
separate for you to take, so that this one here can exist on its own.)

Jason

Powered by blists - more mailing lists