On Sun, Sep 11, 2016 at 11:12:26PM +0200, Florian Westphal wrote:
> Liping Zhang <zlpnobody@xxxxxxx> wrote:
> > From: Liping Zhang <liping.zhang@xxxxxxxxxxxxxx>
> >
> > 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.
Are you think of xor hashing to provide the symmetry? Downside is that
bad tuple selection may result in poor distribution, but this is
something we can document.
Still it would be possible to use jhash at the cost of having two
rules.
It would be great to get a new NFTA_HASH_MODE attribute and something
like:
enum nft_hash_types {
NFT_HASH_JENKINS = 0,
};
So we have room to make other hash algos fit into this expression.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
