Re: [PATCH nf-next RFC 2/3] xt_statistic: do nth-mode accounting per CPU

[Florian Westphal <fw@strlen.de>]

Florian Westphal <fw@strlen.de> wrote:
> Jesper Dangaard Brouer <hawk@kernel.org> wrote:
> > The atomic cmpxchg operations for the nth-mode matching is a scaling
> > concern, on our production servers with 192 CPUs. The iptables rules that
> > does sampling of every 10000 packets exists on INPUT and OUTPUT chains.
> > Thus, these nth-counter rules are hit for every packets on the system with
> > high concurrency.
>  
> > Our use-case is statistical sampling, where we don't need an accurate packet
> > across all CPUs in the system. Thus, we implement per-CPU counters for the
> > nth-mode match.
> > 
> > This replaces the XT_STATISTIC_MODE_NTH, to avoid having to change userspace
> > tooling. We keep and move atomic variant under XT_STATISTIC_MODE_NTH_ATOMIC
> > mode, which userspace can easily be extended to leverage if this is
> > necessary.
> 
> This patch seems acceptable to me (aside from the deliberate userspace
> breakage).
> 
> But I do wonder why you can't move to random sampling instead, it
> doesn't suffer from this problem (i.e. -m statistic --mode random).

Addendum, did not think of this before.  Another alternative is to
prefix '-m statistic' with '-m cpu' so only one core will do the
sampling.  If this should be done on all cpus then xtables
framework would require n rules for n cpus which scales poorly.

In nftables one could use verdict map with 'meta cpu' as a hash key,
then one would be able to fanout based on processing cpu.