netdev - Re: [RFC] [PATCH] net: Add support for ndo_select_queue() functions to cache the queue mapping

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:	Thu, 28 Jan 2010 18:34:34 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org, linux-net-drivers@...arflare.com
Subject: Re: [RFC] [PATCH] net: Add support for ndo_select_queue()
	functions to cache the queue mapping

On Thu, 2010-01-28 at 10:00 -0800, Stephen Hemminger wrote:
> On Thu, 28 Jan 2010 17:38:37 +0000
> Ben Hutchings <bhutchings@...arflare.com> wrote:
> 
> > We think it's worth matching up RX and TX queue selection for a socket
> > when the queues share an interrupt.  Currently the default TX queue
> > selection is unlikely to match RX queue selection.  TX queue selectionc
> > can be overridden by the driver to match RX queue selection, but at the
> > expense of caching.  We found that without caching the cost of
> > recalculating the the hash in software for each packet outweighed the
> > benefit of good queue selection.
> 
> Will this work with RPS and device driver hashing?

If the device only has a single TX queue this can't possibly help it.

In the case where a device has multiple RX and TX queues, I think it is
preferable that contention for TX queues is likely to be among cores
that are close together, not spread over the whole system.  I assume
that RPS will normally be configured to spread traffic from each
hardware RX queue to a group of cores that are close together (same NUMA
mode, maybe sharing some caches).  In that case it would also be
desirable to limit contention for a TX queue to within these same groups
of cores, so TX queue selection ought to match hardware RX queue
selection.  So I don't think this should conflict with RPS.

> I am thinking of the problem where the hardware hash function is
> Toeplitz (per NDIS spec), and the software hash function is Jhash
> (what kernel uses because it is cheaper).
> 
> Therefore the transmit hash and receiver hash will be different.

The intent here is to make it worthwhile to calculate that expensive
hash on the TX side.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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