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
