Re: [PATCH nf-next 8/8] nft_set_pipapo: Introduce AVX2-based lookup implementation

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 20 Nov 2019 17:08:00 +0100
Phil Sutter <phil@nwl.cc> wrote:

> On Wed, Nov 20, 2019 at 04:16:53PM +0100, Florian Westphal wrote:
> > Stefano Brivio <sbrivio@redhat.com> 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@nwl.cc (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