From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 22 Jul 2008 00:16:16 +0800

quoted text
> On Mon, Jul 21, 2008 at 08:26:27AM -0700, David Miller wrote:
> >
> > It is totally unwise to do CPU based TX hashing.
> 
> Right I'm not suggesting having this as a default.  However,
> if you have a finely tuned system (e.g., a router) where you've
> pinned all you RX queues to specific CPUs and your local apps
> as well then it would make sense to provide this as an alternative.
> 
> If this alternative doesn't exist, then unless the RX hash happens
> to match the TX hash, for routing at least the packets are going
> to jump all over the place which isn't nice.

Where are these places they are going to "jump all over"? :-)

You can view the RX and TX queues as roughly independent namespaces.

If the TX hash is good enough (current one certainly isn't and I will
work on fixing that), it is likely to spread the accesses enough that
there won't be many collisions to matter.

If you really think about it, this is even pointless.  Packets that
hit RX queue A will always hit TX queue B, and so on and so forth.
Therefore there will be no new level of separation afforded by using
some kind of strict RX to TX mapping.

We could provide the option, but it is so dangerous and I also see no
real tangible benfit from it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html