On Mon, Aug 26, 2019 at 05:40:06PM +0200, Phil Sutter wrote: > On Sat, Aug 24, 2019 at 06:53:34PM +0200, Pablo Neira Ayuso wrote: > > On Wed, Aug 21, 2019 at 11:26:02AM +0200, Phil Sutter wrote: > > [...] > > > +/* XXX: move this into libnftnl, replacing nftnl_set_lookup() */ > > > +static struct nftnl_set *nft_set_byname(struct nft_handle *h, > > > + const char *table, const char *set) > > > > Probably extend libnftnl to allow to take a pointer to a nftnl_set > > object, as an alternative to the set name? The idea is that this > > set object now belongs to the lookup extension, so this extension will > > take care of releasing it from the destroy path. > > > > Then, the lookup extension will have a pointer to the anonymous set so > > you could then skip the cache code (and all the updates to have access > > to it). > > Sounds like a nice approach! So I would add a new > NFTNL_EXPR_LOOKUP_SET_PTR to link the set and introduce > NFTA_LOOKUP_ANON_SET (or so) which starts a nested attribute filled > simply by nftnl_set_nlmsg_build_payload()? Kernel code would have to be > extended accordingly, of course. No need for kernel code update. > Seems like I can't reuse nftnl_set_nlmsg_parse() since > mnl_attr_parse_nested() would have to be called. But I guess outsourcing > the attribute handling from the further and introducing a second wrapper > would do. My proposal is to add NFTNL_EXPR_LOOKUP_SET_PTR, that allows you to pass a pointer to the set, if that makes this simpler for you. This would be an alias of the SET_ID, from the build path it would use. You would still need to add the set command. But I think you will end up needing the set cache anyway from the netlink dump path anyway. I'm re-evaluating, and I think your patchset is a good approach.
