linux-kernel - Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer

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: <20090314015340.GM11935@one.firstfloor.org>
Date:	Sat, 14 Mar 2009 02:53:40 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Tom Herbert <therbert@...gle.com>
Cc:	David Miller <davem@...emloft.net>, yanmin_zhang@...ux.intel.com,
	bhutchings@...arflare.com, andi@...stfloor.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	herbert@...dor.apana.org.au, jesse.brandeburg@...el.com,
	shemminger@...tta.com
Subject: Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer

> Yes, we are using a 10G NIC that supports multi-queue.  The number of
> RX queues supported is half the number of cores on our platform, so
> that is going to limit the parallelism.  With multi-queue turned on we

The standard wisdom is that you don't necessarily need to transmit
to each core, but rather to each shared mid or least level cache.
Once the data is cache hot (or cache near) distributing it further
in software is comparable cheap.

So this means you don't necessarily need as many queues as cores,
but more as many as big caches.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/