From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
Netdev <netdev@vger.kernel.org>,
"Adhipati Blambangan" <adhipati@tuta.io>,
"David Ahern" <dsahern@gmail.com>
Subject: Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic skb handler
Date: Mon, 27 Apr 2020 17:45:12 -0600 [thread overview]
Message-ID: <CAHmME9r6Vb7yBxBsLY75zsqROUnHeoRAjmSSfAyTwZtzcs_=kg@mail.gmail.com> (raw)
In-Reply-To: <CAHmME9r7G6f5y-_SPs64guH9PrG8CKBhLDZZK6jpiOhgHBps8g@mail.gmail.com>
On Mon, Apr 27, 2020 at 5:00 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Mon, Apr 27, 2020 at 3:31 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Mon, 27 Apr 2020 23:14:05 +0200 Toke Høiland-Jørgensen wrote:
> > > 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...
> >
> > I wonder, maybe our documentation is not clear. IOW we were saying that
> > XDP is a faster cls_bpf, which leaves out the part that XDP only makes
> > sense for HW/virt devices.
> >
> > Kinda same story as XDP egress, folks may be asking for it but that
> > doesn't mean it makes sense.
> >
> > Perhaps the original reporter realized this and that's why they
> > disappeared?
> >
> > My understanding is that XDP generic is aimed at testing and stop gap
> > for drivers which don't implement native. Defining behavior based on
> > XDP generic's needs seems a little backwards, and risky.
> >
> > That said, I don't feel particularly strongly about this.
>
> Okay, well, I'll continue developing the v3 approach a little further
> -- making sure I have tx path handled too and whatnot. Then at least
> something viable will be available, and you can take or leave it
> depending on what you all decide.
Actually, it looks like egress XDP still hasn't been merged. So I
think this patch should be good to go in terms of what it is.
next prev parent reply other threads:[~2020-04-27 23:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 1:10 [PATCH RFC v1] net: xdp: allow for layer 3 packets in generic skb handler Jason A. Donenfeld
2020-04-27 7:20 ` Toke Høiland-Jørgensen
2020-04-27 10:05 ` Jason A. Donenfeld
2020-04-27 10:22 ` [PATCH RFC v2] " Jason A. Donenfeld
2020-04-27 11:16 ` Toke Høiland-Jørgensen
2020-04-27 14:45 ` David Ahern
2020-04-27 19:58 ` Jason A. Donenfeld
2020-04-27 20:08 ` Toke Høiland-Jørgensen
2020-04-27 20:10 ` Jason A. Donenfeld
2020-04-27 20:42 ` [PATCH net v3] net: xdp: account " Jason A. Donenfeld
2020-04-27 20:52 ` Jakub Kicinski
2020-04-27 20:57 ` Jason A. Donenfeld
2020-04-27 21:00 ` Jakub Kicinski
2020-04-27 21:08 ` Jason A. Donenfeld
2020-04-27 21:19 ` Jakub Kicinski
2020-04-27 21:14 ` Toke Høiland-Jørgensen
2020-04-27 21:31 ` Jakub Kicinski
2020-04-27 23:00 ` Jason A. Donenfeld
2020-04-27 23:45 ` Jason A. Donenfeld [this message]
2020-04-28 0:15 ` Jakub Kicinski
2020-04-28 0:17 ` Jason A. Donenfeld
2020-04-28 0:40 ` Jakub Kicinski
2020-04-28 9:27 ` Toke Høiland-Jørgensen
2020-04-28 16:51 ` Jakub Kicinski
2020-04-28 17:03 ` Alexei Starovoitov
2020-04-27 21:00 ` Toke Høiland-Jørgensen
2020-04-27 10:30 ` [PATCH RFC v1] net: xdp: allow " Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHmME9r6Vb7yBxBsLY75zsqROUnHeoRAjmSSfAyTwZtzcs_=kg@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=adhipati@tuta.io \
--cc=dsahern@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).