Jakub Kicinski <kuba@xxxxxxxxxx> writes: > On Fri, 04 Dec 2020 10:38:06 +0100 Toke Høiland-Jørgensen wrote: >> Jakub Kicinski <kuba@xxxxxxxxxx> writes: >> > On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote: >> >> Since we offloaded and non-offloaded programs can co-exist there doesn't >> >> really seem to be any reason for the check anyway, and it's only used in >> >> three drivers so let's just get rid of the callback entirely. >> > >> > I don't remember exactly now, but I think the concern was that using >> > the unspecified mode is pretty ambiguous when interface has multiple >> > programs attached. >> >> Right. I did scratch my head a bit for why the check was there in the >> first place, but that makes sense, actually :) >> >> So how about we disallow unload without specifying a mode, but only if >> more than one program is loaded? > > Are you including replacing as a form of unload? :) Yeah, that's what I ended up with (in v2): Any time there are multiple programs loaded, callers have to specify a mode flag to avoid ambiguity. > IMHO the simpler the definition of the API / constraint the better. > "You must specify the same flags" is pretty simple, as is copying the > old behavior rather than trying to come up with new rules. > > But up to you, I don't mind either way, really.. Well that old behaviour was what led me to investigate this in the first place: If you just look at a program that's loaded, see it's in driver mode, and then try to unload it with flags set to XDP_MODE_DRV, it will sometimes work and sometimes not depending on what flags that program happened to have been loaded with. In libxdp this is exactly what we do (look at the loaded program and set the corresponding mode flag), so I ended up getting some really odd bug reports... So I really don't want to keep the current behaviour; if what I propose in v2 is OK with you I think we should just go with that :) -Toke
