archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <>
To: Jakub Kicinski <>
Cc: Netdev <>,
	"Thomas Ptacek" <>,
	"Adhipati Blambangan" <>,
	"David Ahern" <>,
	"Toke Høiland-Jørgensen" <>,
	"Alexei Starovoitov" <>
Subject: Re: [PATCH net v4] net: xdp: account for layer 3 packets in generic skb handler
Date: Fri, 14 Aug 2020 23:04:56 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 8/14/20, Jakub Kicinski <> wrote:
> On Fri, 14 Aug 2020 08:56:48 +0200 Jason A. Donenfeld wrote:
>> On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski <> wrote:
>> > > I had originally dropped this patch, but the issue kept coming up in
>> > > user reports, so here's a v4 of it. Testing of it is still rather
>> > > slim,
>> > > but hopefully that will change in the coming days.
>> >
>> > Here an alternative patch, untested:
>> Funny. But come on now... Why would we want to deprive our users of
>> system consistency?
> We should try for consistency between xdp and cls_bpf instead.

And still require users to reimplement their packet processing logic twice?

>> Doesn't it make sense to allow users to use the same code across
>> interfaces? You actually want them to rewrite their code to use a
>> totally different trigger point just because of some weird kernel
>> internals between interfaces?
> We're not building an abstraction over the kernel stack so that users
> won't have to worry how things work. Users need to have a minimal
> understanding of how specific hooks integrate with the stack and what
> they are for. And therefore why cls_bpf is actually more efficient to
> use in L3 tunnel case.

It's not like adding 7 lines of code constitutes adding an abstraction
layer. It's a pretty basic fix to make real things work for real
users. While you might argue that users should do something different,
you also can't deny that being able to hook up the same packet
processing to eth0, eth1, extrafancyeth2, and tun0 is a huge

>> Why not make XDP more useful and more generic across interfaces? It's
>> very common for systems to be receiving packets with a heavy ethernet
>> card from the current data center, in addition to receiving packets
>> from a tunnel interface connected to a remote data center, with a need
>> to run the same XDP program on both interfaces. Why not support that
>> kind of simplicity?
>> This is _actually_ something that's come up _repeatedly_. This is a
>> real world need from real users who are doing real things. Why not
>> help them?
> I'm sure it comes up repeatedly because we don't return any errors,
> so people waste time investigating why it doesn't work.

What? No. It comes up repeatedly because people want to reuse their
XDP processing logic with layer 3 devices. You might be right that if
we tell them to go away, maybe they will, but on the other hand, why
not make this actually work for them? It seems pretty easy to do, and
saves everyone a lot of time.

Are you worried about adding a branch to the
already-slower-and-discouraged non-hardware generic path? If so, I
wouldn't object if you wanted to put unlikely() around the branch
condition in that if statement.


  reply	other threads:[~2020-08-14 21:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 19:58 [PATCH net v4] net: xdp: account for layer 3 packets in generic skb handler Jason A. Donenfeld
2020-08-13 21:01 ` Jakub Kicinski
2020-08-14  6:56   ` Jason A. Donenfeld
2020-08-14  7:30     ` [PATCH net v5] " Jason A. Donenfeld
2020-08-14 20:55       ` David Miller
2020-08-14 20:57         ` Jason A. Donenfeld
2020-08-15  7:41         ` [PATCH net v6] " Jason A. Donenfeld
2020-08-19  7:07           ` Jesper Dangaard Brouer
2020-08-19 23:22           ` David Miller
2020-08-20  9:13             ` Jason A. Donenfeld
2020-08-20 18:55               ` David Miller
2020-08-20 20:29                 ` Jason A. Donenfeld
2020-08-14 15:31     ` [PATCH net v4] " Jakub Kicinski
2020-08-14 21:04       ` Jason A. Donenfeld [this message]
2020-08-14 21:26         ` David Miller
2020-08-15  7:54           ` Jason A. Donenfeld
2020-08-14 21:14       ` David Miller

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \

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