Re: [PATCH v2] netfilter: nft_nth: match every n packets

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Aug 09, 2016 at 04:13:40PM +0200, Laura Garcia wrote:
> On Tue, Aug 09, 2016 at 12:52:53PM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Jul 28, 2016 at 11:20:59AM +0200, Florian Westphal wrote:
> > > Laura Garcia <nevola@gmail.com> wrote:
> > > > On Thu, Jul 28, 2016 at 01:01:05AM +0200, Florian Westphal wrote:
> > > > > How exactly is this used by nftables?
> > > > > 
> > > > > AFAIU usespace will check if ->dreg is 0 or not, but does that make
> > > > > sense?
> > > > > 
> > > > > Seems to me it would be more straightforward to not use a dreg at all
> > > > > and just NFT_BREAK if nval != 0?
> > > > > 
> > > > 
> > > > The main idea is to provide a round robin like scheduling method, for
> > > > example:
> > > > 
> > > > ip daddr <ipsaddr> dnat nth 3 map {
> > > >         0: <ipdaddrA>,
> > > >         1: <ipdaddrB>,
> > > >         2: <ipdaddrC>
> > > > }
> > > > 
> > > 
> > > That makes sense, would be nice to place a small blurb in the commit
> > > message.
> > 
> > I'd suggest you rename this to nft_numgen.c where numgen stands for
> > 'number generator', then rename 'every' to 'until' (this sets the
> > upper limit in the generator) and add support for random too, so we
> > provide incremental and random number generators to start with and we
> > leave room to extend this with more number generators in the future if
> > needed.
> > 
> > Florian added random to meta, but I don't see an easy way to reuse
> > this with maps unless we introduce another modulus/scale expression,
> > and we should skip oversplitting expressions in way too basic
> > operations.
> 
> So, do you mean something like this?
> 
> ip daddr <ipsaddr> dnat numgen nth 3 map {
>         0: <ipdaddrA>,
>         1: <ipdaddrB>,
>         2: <ipdaddrC>
> }
> 
> and
> 
> ip daddr <ipsaddr> dnat numgen random 3 map {
>         0: <ipdaddrA>,
>         1: <ipdaddrB>,
>         2: <ipdaddrC>
> }

Something like this, but I would like to have a better syntax for
this.

> Maybe _math_ could be a better name?
> The counter expression could be included as well.

We already have a counter expression ;-) So what counter expression
are you refering to?