On Wed, Nov 20, 2019 at 04:16:53PM +0100, Florian Westphal wrote: > Stefano Brivio <sbrivio@xxxxxxxxxx> wrote: > > If the AVX2 set is available, we can exploit the repetitive > > characteristic of this algorithm to provide a fast, vectorised > > version by using 256-bit wide AVX2 operands for bucket loads and > > bitwise intersections. > > > > In most cases, this implementation consistently outperforms rbtree > > set instances despite the fact they are configured to use a given, > > single, ranged data type out of the ones used for performance > > measurements by the nft_concat_range.sh kselftest. > > I think in that case it makes sense to remove rbtree once this new > set type has had some upstream exposure and let pipapo handle the > range sets. > > Stefano, if I understand this right then we could figure out which > implementation (C or AVX) is used via "grep avx2 /proc/cpuinfo". > > If not, I think we might want to expose some additional debug info > on set dumps. I once submitted a patch introducing NFTA_SET_OPS, an attribute holding set type's name in dumps. Maybe we can reuse that? It is message ID 20180403211540.23700-3-phil@xxxxxx (Subject: [PATCH v2 2/2] net: nftables: Export set backend name via netlink). Cheers, Phil
