On Fri, 2 Aug 2019 21:09:03 +0800, wenxu wrote:
> >> We'd have something like the loop in flow_get_default_block():
> >>
> >> for each (subsystem)
> >> subsystem->handle_new_indir_cb(indr_dev, cb);
> >>
> >> And then per-subsystem logic would actually call the cb. Or:
> >>
> >> for each (subsystem)
> >> block = get_default_block(indir_dev)
> >> indr_dev->ing_cmd_cb(...)
> > nft dev chian is also based on register_netdevice_notifier, So
> > for unregister case,
> >
> > the basechian(block) of nft maybe delete before the
> > __tc_indr_block_cb_unregister. is right?
> >
> > So maybe we can cache the block as a list of all the subsystem in indr_dev
> > ?
>
>
> when the device is unregister the nft netdev chain related to this device
> will also be delete through netdevice_notifier
>
> . So for unregister case,the basechian(block) of nft maybe delete before the
> __tc_indr_block_cb_unregister.
Hm, but I don't think that should be an issue. The ordering should be
like one of the following two:
device unregister:
- driver notifier callback
- unregister flow cb
- UNBIND cb
- free driver's block state
- free driver's device state
- nft block destroy
# doesn't see driver's CB any more
Or:
device unregister:
- nft block destroy
- UNBIND cb
- free driver's block state
- driver notifier callback
- free driver's state
No?
> cache for the block is not work because the chain already be delete and free.
> Maybe it improve the prio of
>
> rep_netdev_event can help this?
In theory the cache should work in a similar way as drivers, because
once the indr_dev is created and the initial block is found, the cached
value is just recorded in BIND/UNBIND calls. So if BIND/UNBIND works for
drivers it will also put the right info in the cache.
