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: <20090128.164058.248259991.davem@davemloft.net>
Date:	Wed, 28 Jan 2009 16:40:58 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue
 hashing.

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Thu, 29 Jan 2009 08:31:41 +1100

> On Wed, Jan 28, 2009 at 12:22:31PM -0800, David Miller wrote:
> >
> > No matter what you think about the randomness aspect, our
> > divide avoidance technique being used here will still
> > get in the way of the situations you seem to be concerned
> > about.
> > 
> > We do the jhash et al. magic in order to be able to use a
> > multiply to get the modulus.  So the function computing from
> > RX to TX queue numbers will never be straightforward.
> 
> Right, if the number of queues weren't equal then clearly it's
> not an issue to tack on more randomness.  But I was thinking of
> scenarios where you have two identical NICs, performing routing
> where the number of queues is likely to be identical.

It is even the same for "identical" NICs.  Robert Olsson knows this
quite well :-)

For example, with the NIU chips the number of TX queues is larger
than the number of RX queues.

Robert has been proposing some ideas wherein some mapping is
implemented such that we iterate over a group of TX queues
per RX queue.

Otherwise in a routing workload some of the TX queues become
unused.

That's a fun hack for testing when you know the characteristics of
all of the devices in your system, but doesn't generalize well.

It's a tricky thing because we don't know where we're sending to of
course.  It shows that the "RX queue number" is not a sufficient
seed.

One way to deal with this is to grab the hash the chip computed.
I'm reluctant to advocate this because it's expensive with NIU
because I have to start using the larger RX descriptor layout
to get at that cookie.  (see "rx_pkt_hdr0" vs. "rx_pkt_hdr1" in
drivers/net/niu.h)

And I suspect other cards will require similar tradeoffs.
--
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