From: Eric Dumazet <dada1@cosmosbay•com>
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: David Miller <davem@davemloft•net>, netdev@vger•kernel.org
Subject: Re: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue hashing.
Date: Wed, 28 Jan 2009 10:29:14 +0100 [thread overview]
Message-ID: <4980256A.7050908@cosmosbay.com> (raw)
In-Reply-To: <20090128085358.GA15593@gondor.apana.org.au>
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.
next prev parent reply other threads:[~2009-01-28 9:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 0:40 [PATCH 1/4]: net: Allow RX queue selection to seed TX queue hashing David Miller
2009-01-28 8:53 ` Herbert Xu
2009-01-28 9:29 ` Eric Dumazet [this message]
2009-01-28 20:22 ` David Miller
2009-01-28 21:31 ` Herbert Xu
2009-01-29 0:40 ` David Miller
2009-01-29 1:34 ` Herbert Xu
2009-01-29 1:45 ` David Miller
2009-01-29 4:41 ` Herbert Xu
2009-01-29 5:01 ` David Miller
2009-01-28 18:50 ` Brandeburg, Jesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4980256A.7050908@cosmosbay.com \
--to=dada1@cosmosbay$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox