Hi again Phil,
On Wed, Jun 19, 2024 at 05:59:32PM +0200, Phil Sutter wrote:
[...]
> I assumed your intention was for NFTA_HOOK_DEVS to not change
> semantically, i.e. remain to contain only devices which are present at
> time of the dump. Then I could introduce INACTIVE_DEVS to contain those
> we lost meanwhile. As an example:
>
> 1) add netdev chain for devices eth0, eth1, eth2
> 2) list ruleset:
> - HOOK_DEVS = { eth0, eth1, eth2 }
> - INACTIVE_DEVS = {}
> 3) ip link del eth1
> 4) list ruleset:
> - HOOK_DEVS = { eth0, eth2 }
> - INACTIVE_DEVS = { eth1 }
>
> This avoids duplicate entries in both lists and thus avoids overhead.
> This would fix for the interfaces missing in dumps problem.
>
> Wildcards would appear as-is in either HOOK_DEVS (if there's at least
> one matching interface) or INACTIVE_DEVS (if there is none). The actual
> list of active interfaces would require a GETDEVICE call.
[...]
> OK, let's see if I can sum this up correctly:
>
> 1) NFTA_HOOK_DEVS is changed to always reflect what the user specified
> 2) Interfaces being removed or added trigger NEWDEV/DELDEV notifications
> 3) Active hooks are dumped by GETDEV netlink request
> 4) NEWDEV/DELDEV netlink requests/responses added to cover for oversized
> chains/flowtables
It should be possible to use:
nft list hooks
to display the flowtable
if user specifies the device, then it displays the ingress patch from
the given device, the flowtable hook could be shown there for
debugging purpose.
Then, there is no need for the ACTIVE_DEVS/INACTIVE_DEVS attribute.
Rewinding a bit: The NEWDEV/DELDEV interface I am proposing has a
downside, which is that userspace has to deal with two interfaces to
add netdevice to basechain/flowtables (currently NEWCHAIN/NEWFLOWTABLE
can be used for this purpose).
Probably I am overdoing a bit with this new interface.
Then, there is the concern with NLMSG_GOODSIZE, but it should be
possible to deliver independent notifications to userspace via
NEWCHAIN/NEWFLOWTABLE including only the netdevices, ie. allocate one
transaction for each new netdevice, so one notification is send per
new netdevice.
In summary: If ACTIVE_DEVS/INACTIVE_DEVS can go away, and nft list
hooks is used instead to check if there is a hook registered for such
device matching the wildcard netdevice, eg. tap*, then your existing
patch can be used as is.
As said, only purpose to know if the device is registered is
debugging, if user requires tap*, then if tap0 exists it is
registered, otherwise it is a kernel bug.
Apologies for this u-turn a bit, this is taking you back to this
original patch of you minus ACTIVE_DEVS/INACTIVE_DEVS and document
that 'nft link hooks' can be use to check if the netdevice got a hook
registered for the flowtable/basechain.
Thanks.
