在 2019/8/3 2:02, Jakub Kicinski 写道: > 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? For the second case maybe can't unbind cb? because the nft block is destroied. There is no way to find the block(chain) in nft. > >> 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. >
