Re: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue hashing.

[Eric Dumazet <dada1@cosmosbay.com>]

Herbert Xu a écrit :
> David Miller <davem@davemloft.net> wrote:
>> +       if (skb_rx_queue_recorded(skb)) {
>> +               u32 val = skb_get_rx_queue(skb);
>> +
>> +               hash = jhash_1word(val, simple_tx_hashrnd);
> 
> I'm not so sure about this added randomness.  On the one hand
> I can see the benefit in being defensive about hashing, but this
> does pose a problem for admins who're trying to optimse the system
> by tying RX interrupts together with TX interrupts for the most
> common traffic path.
> 
> For example, if you're forwarding traffic between multiqueue NICs
> A and B, one would like to make it so that each queue on A goes
> to a fixed queue on B where the CPU of the RX queue IRQ handler on
> A is the same as the CPU of the TX queue IRQ handler on B.
> 
> This can still be done with the randomness, but it is much more
> difficult.  Also if the randomness changes, we'd have to rejig
> the IRQ assignment.
> 
> So can you think of a scenario where we really need this added
> protection?
> 
jhash_1word(val, some_32bits_value) has a shuffle property we want to keep.

Maybe we can add a boot parameter so that admins who're trying to
optimize their system can fix a given value (yet not known to outsiders)
for simple_tx_hashrnd. This way, they know next reboots will keep
same hash function.