On Sat, Jul 11, 2020 at 12:18:13PM +0200, Phil Sutter wrote: > Work in this series centered around Harald's complaint about seemingly > random custom chain ordering in iptables-nft-save output. nftables > returns chains in the order they were created which differs from > legacy iptables which sorts by name. > > The intuitive approach of simply sorting chains in tables' > nftnl_chain_lists is problematic since base chains, which shall be > dumped first, are contained in there as well. Patch 15 solves this by > introducing a per-table array of nftnl_chain pointers to hold only base > chains (the hook values determine the array index). The old > nftnl_chain_list now contains merely non-base chains and is sorted upon > population by the new nftnl_chain_list_add_sorted() function. > > Having dedicated slots for base chains allows for another neat trick, > namely to create only immediately required base chains. Apart from the > obvious case, where adding a rule to OUTPUT chain doesn't cause creation > of INPUT or FORWARD chains, this means ruleset modifications can be > avoided completely when listing, flushing or zeroing counters (unless > chains exist). Patches from 1 to 7, they look good to me. Would it be possible to apply these patches independently from this batch or they are a strong dependency? I think it's better if we go slightly different direction? https://patchwork.ozlabs.org/project/netfilter-devel/patch/20200723121553.7400-1-pablo@xxxxxxxxxxxxx/ Instead of adding more functions into libnftnl for specific list handling, which are not used by nft, use linux list native handling. I think there is not need to cache the full nftnl_table object, probably it should be even possible to just use it to collect the attributes from the kernel to populate the nft_table object that I'm proposing. IIRC embedded people complained on the size of libnftnl, going this direction I suggest, we can probably deprecated iterators for a number of objects and get it slimmer in the midrun. WDYT?
