[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090128085358.GA15593@gondor.apana.org.au>
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
Powered by blists - more mailing lists