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

[Florian Westphal <fw@strlen.de>]

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.