On Wed, 20 Nov 2019 17:08:00 +0100 Phil Sutter <phil@xxxxxx> wrote: > 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". In practice, that's correct. Strictly speaking, this is not portable, because other architectures might decide to have an 'avx2' flag that means something different, so... > > 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). ...I would rather try to introduce this at a later time. I just wonder: what was the problem with that series? :) -- Stefano
