[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F169D4F5E1F1974DBFAFABF47F60C10A1C225B4C@orsmsx507.amr.corp.intel.com>
Date: Wed, 28 Jan 2009 10:50:58 -0800
From: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 1/4]: net: Allow RX queue selection to seed TX queue
hashing.
David Miller wrote:
> The idea is that drivers which implement multiqueue RX
> pre-seed the SKB by recording the RX queue selected by
> the hardware.
>
> If such a seed is found on TX, we'll use that to select
> the outgoing TX queue.
>
> This helps get more consistent load balancing on router
> and firewall loads.
>
> Signed-off-by: David S. Miller <davem@...emloft.net>
> ---
> include/linux/skbuff.h | 15 +++++++++++++++
> net/core/dev.c | 8 ++++++++
> 2 files changed, 23 insertions(+), 0 deletions(-)
Hi Dave, thanks for doing this work, it looks very interesting, I'm curious
what you think should happen with the tx / rx interrupts when every queue has
a unique interrupt number.
I don't think the irqbalance daemon is smart enough to know that a given
tx queue should always end up either cache coherent (different core) or
core-coherent (same core) to the rx queue.
So, is it still expected that users running routing setups will always
have to hand-tune /proc/irq/NNN/smp_affinity for each of the tx and rx
queues?
Ideally the routing case would somehow end up working like the socket case
where the scheduler would notice the wakeups cross cpu and move the interrupt
for the routing case in the same way (I assume from your previous comments) it
would move the interrupt for a socket based application.
I hope to be able to test this today or tomorrow.--
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
Powered by blists - more mailing lists