[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zw5Sj6ODbaMyLrrf@fedora>
Date: Tue, 15 Oct 2024 11:31:27 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: Nikolay Aleksandrov <razor@...ckwall.org>
Cc: Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Andrii Nakryiko <andriin@...com>, Jussi Maki <joamaki@...il.com>,
Jay Vosburgh <jv@...sburgh.net>, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, Liang Li <liali@...hat.com>
Subject: Re: [PATCH net] bpf: xdp: fallback to SKB mode if DRV flag is absent.
On Tue, Oct 15, 2024 at 01:46:53PM +0300, Nikolay Aleksandrov wrote:
> > This should not be a behaviour change, it just follow the fallback rules.
>
> hm, what fallback rules? I see dev_xdp_attach() exits on many errors
> with proper codes and extack messages, am I missing something, where's the
> fallback?
I mean in the `man ip link` page [1], it said
ip link output will indicate a xdp flag for the networking device. If the
driver does not have native XDP support, the kernel will fall back to a
slower, driver-independent "generic" XDP variant.
>
> >> IMO it's better to explicitly
> >> error out and let the user decide how to resolve the situation.
> >
> > The user feels confused and reported a bug. Because cmd
> > `ip link set bond0 xdp obj xdp_dummy.o section xdp` failed with "Operation
> > not supported" in stead of fall back to xdpgeneral mode.
> >
>
> Where's the nice extack msg then? :)
>
> We can tell them what's going on, maybe they'll want to change the bonding mode
> and still use this mode rather than falling back to another mode silently.
> That was my point, fallback is not the only solution.
Yes, that's also a good solution. My goal is to either inform the user why
the XDP program couldn't be loaded, or load it in SKB mode if the user
hasn't specifically requested XDPDRV mode. Otherwise, the user might be
confused about why the kernel didn't automatically fall back to SKB mode.
Thanks
Hangbin
Powered by blists - more mailing lists