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]

Date:	Wed, 28 Jan 2009 19:53:58 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue
	hashing.

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?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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