Re: [PATCH nf-next] netfilter: nft_queue: add _SREG_FROM and _SRGE_TO to select the queue numbers

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

On Mon, Sep 12, 2016 at 02:28:49PM +0200, Florian Westphal wrote:
> Laura Garcia <nevola@gmail.com> wrote:
> > On Sun, Sep 11, 2016 at 11:12:26PM +0200, Florian Westphal wrote:
> > > Liping Zhang <zlpnobody@163.com> wrote:
> > > > From: Liping Zhang <liping.zhang@spreadtrum.com>
> > > > 
> > > > Currently, the user can specify the queue numbers by _QUEUE_NUM and
> > > > _QUEUE_TOTAL attributes, this is enough in most situations.
> > > > 
> > > > But acctually, it is not very flexible, for example:
> > > >   tcp dport 80 mapped to queue0
> > > >   tcp dport 81 mapped to queue1
> > > >   tcp dport 82 mapped to queue2
> > > > In order to do this thing, we must add 3 nft rules, and more
> > > > mapping means more rules ...
> > > > 
> > > > So similer to nft_nat, take two registers to select the queue numbers,
> > > > then we can add one simple rule to mapping queues, maybe like this:
> > > >   queue num tcp dport map { 80:0, 81:1, 82:2 ... }
> > > 
> > > I like this.
> > > 
> > > My first thought was that it would be better to just support one single
> > > sreg (the queue number) and eventually externalize the hashing/queue
> > > selection:
> > > 
> > > queue num jhash ip saddr . ip daddr mod ...
> > > 
> > > Problem is that with plain jhash we won't get a symmetric hash
> > > for origin and reply, so for this we would need a new expression/hash
> > > mode.
> > > 
> > > We would also need another expression to allow distribution
> > > starting with a queue other than 0.
> > 
> > For such feature, I've already sent a patch "netfilter: nft_hash: Add
> > hash offset value" in order to set an initial value for the hash
> > expression. I think it'll be available in the tree soon.
> 
> Yes, but that means one would always need to use hash.
> 
> Maybe thats indeed sufficient since it already provides a modulo
> functionality.
> 
> I was thinking
> 
> nfqueue num meta cpu ...
> nfqueue num meta hash ... [ i.e. use skb->hash, not supported right now ]
> nfqueue num meta mark
> nfqueue num ct mark
> 
> etc.  so we would have no control over start qnum (something like
> 'nfqueue num (meta cpu + 10000)' ...
>
> Admittingly, I do not see a big drawback if we'd always have to
> feed it to jhash first.

I think it would be easy to add this offset support to meta and ct, so
we adding this value to whatever we fetch. I think a generic
arithmetic expression that allows us to add two values from two
registers is too much.