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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4980256A.7050908@cosmosbay.com>
Date:	Wed, 28 Jan 2009 10:29:14 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue	hashing.

Herbert Xu a écrit :
> David Miller <davem@...emloft.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.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html