From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>, netdev@vger.kernel.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: Re: [PATCH RFC v2] net: xdp: allow for layer 3 packets in generic skb handler
Date: Mon, 27 Apr 2020 13:16:22 +0200 [thread overview]
Message-ID: <87ftcpyy9l.fsf@toke.dk> (raw)
In-Reply-To: <20200427102229.414644-1-Jason@zx2c4.com>
"Jason A. Donenfeld" <Jason@zx2c4.com> writes:
> A user reported a few days ago that packets from wireguard were possibly
> ignored by XDP [1]. We haven't heard back from the original reporter to
> receive more info, so this here is mostly speculative. Successfully nerd
> sniped, Toke and I started poking around. Toke noticed that 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 is untested, but I
> wanted to gauge interest in this approach: 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.
Seems to me like this would work; let's see if anyone else has any
comments :)
-Toke
next prev parent reply other threads:[~2020-04-27 11:16 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 [this message]
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
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=87ftcpyy9l.fsf@toke.dk \
--to=toke@redhat.com \
--cc=Jason@zx2c4.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.