Hi Florian,
On Fri, May 05, 2023 at 02:32:08PM +0200, Florian Westphal wrote:
> Following dummy ruleset only works on first load:
>
> $ cat bug
> flush ruleset
> table inet filter {
> flowtable f1 {
> hook ingress priority 10
> flags offload
> devices = { dummy0, dummy1 }
> }
> }
> $ nft -f bug
This follows flowtable addition path.
> $ nft -f bug
This follows nft_flow_update() path.
> bug:3:13-14: Error: Could not process rule: Device or resource busy
I don't see who reports EBUSY at quick glance.
nft_flowtable_update() removes redundant hooks (already registered).
> This works when 'offload' flag is removed.
>
> Transaction will *first* try to register the flowtable hook,
> then it unregisters the existing flowtable hook.
>
> When 'offload' flag is enabled, hook registration fails because
> the device offload capability is already busy.
>
> Any suggestions on how to fix this?
> Or would you say this is as expected/designed?
It should not report EBUSY, we have fixed similar issues like this one
in the past.
> I don't see a way to resolve this.
>
> We could swap register/unregister, but this has two major issues:
>
> 1. it gives a window where no hook is registered on hw side
> 2. after unreg, we cannot assume that (re)registering works, so
> 'nft -f' may cause loss of functionality.
>
> Adding a 'refcount' scheme doesn't really work either, we'd need
> an extra data structure to record the known offload settings, so that
> on a 'hook flowtable f1 to dummy0' request we can figure out that this
> is expected to be busy and then we could skip the register request.
>
> But that has to problem that the batch might not have an unregister
> request, i.e. we would accept a bogus ruleset that *should* have failed
> with -EBUSY.
>
> Any ideas?
If you help me narrow down the issue, because I currently do not see
where this EBUSY error originates from.
> If not, i'd add a paragraph to the man page wrt. offload caveats.
>
> Thanks,
> Florian
