Hi Pablo, On Fri, Dec 21, 2018 at 02:13:54PM +0100, Phil Sutter wrote: > On Fri, Dec 21, 2018 at 12:41:31PM +0100, Pablo Neira Ayuso wrote: > > On Wed, Dec 12, 2018 at 08:04:12PM +0100, Phil Sutter wrote: > > > Kernel prefers to identify chain by handle if it was given which causes > > > manual traversal of the chain list. In contrast, chain lookup by name in > > > kernel makes use of a hash table so is considerably faster. Force this > > > code path by removing the cached chain's handle when removing it. > > > > > > Signed-off-by: Phil Sutter <phil@xxxxxx> > > > --- > > > iptables/nft.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/iptables/nft.c b/iptables/nft.c > > > index 5ef3a75efcde5..8ff21e09f0344 100644 > > > --- a/iptables/nft.c > > > +++ b/iptables/nft.c > > > @@ -1643,6 +1643,7 @@ static int __nft_chain_user_del(struct nftnl_chain *c, void *data) > > > fprintf(stdout, "Deleting chain `%s'\n", > > > nftnl_chain_get_str(c, NFTNL_CHAIN_NAME)); > > > > > > + nftnl_chain_unset(c, NFTNL_CHAIN_HANDLE); > > > > LGTM. > > > > We can probably add a hashtable for chain handle lookups in the > > kernel too so we can re-enable this in the future. > > Florian suggested to use an rbtree and some seqcount trickery to avoid > concurrency issues. I already started with that but decided I need to > learn more about kernel locking mechanisms before I submit something > stupid. :) I haven't found time yet to work on improved chain lookup by handle in kernel. So for the time being, would you mind applying this iptables patch? It doesn't hurt even with a later improved chain lookup by handle in place. If that is turning out to be even quicker than the current chain lookup by name via hashtable, we may drop this patch again. Thanks, Phil
