From: David Miller <davem@davemloft.net>
To: jelaas@gmail.com
Cc: andrew@whydna.net, netdev@vger.kernel.org
Subject: Re: tx queue hashing hot-spots and poor performance (multiq, ixgbe)
Date: Thu, 30 Apr 2009 02:24:17 -0700 (PDT) [thread overview]
Message-ID: <20090430.022417.07019547.davem@davemloft.net> (raw)
In-Reply-To: <96ff3930904300207l4ecfe90byd6cce3f56ce4e113@mail.gmail.com>
From: Jens Låås <jelaas@gmail.com>
Date: Thu, 30 Apr 2009 11:07:35 +0200
> RX-side looks good. TX-side looks like what we also got with vanilla linux.
>
> What we do is patch all drivers with a custom select_queue function
> that selects the same outgoing queue as the incoming queue. With a one
> to one mapping of queues to CPUs you can also use the processor id.
>
> This way we get performance.
I don't understand why this can even be necessary.
With the current code, the RX queue of a packet becomes
the hash for the TX queue.
If all the TX activity is happening on one TX queue then
there is a bug somewhere.
Either the receiving device isn't invoking skb_record_rx_queue()
correctly, or there is some bug in how we compute the TX hash.
Everyone adds their own hacks, but that absolutely should not be
necessary, the kernel is essentially doing what you are adding
hacks for.
The only possible problems are bugs in the code, and we should find
those bugs instead of constantly talking about 'local select_queue
hacks we add to our cool driver for performance' :-/
next prev parent reply other threads:[~2009-04-30 9:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 23:00 tx queue hashing hot-spots and poor performance (multiq, ixgbe) Andrew Dickinson
2009-04-30 9:07 ` Jens Låås
2009-04-30 9:24 ` David Miller [this message]
2009-04-30 10:51 ` Jens Låås
2009-04-30 11:05 ` David Miller
2009-04-30 14:04 ` Andrew Dickinson
2009-04-30 14:08 ` David Miller
2009-04-30 23:53 ` Andrew Dickinson
2009-05-01 4:19 ` Andrew Dickinson
2009-05-01 7:32 ` Eric Dumazet
2009-05-01 7:47 ` Eric Dumazet
2009-05-01 6:14 ` Eric Dumazet
2009-05-01 6:19 ` Andrew Dickinson
2009-05-01 6:40 ` Eric Dumazet
2009-05-01 7:23 ` Andrew Dickinson
2009-05-01 7:31 ` Eric Dumazet
2009-05-01 7:34 ` Andrew Dickinson
2009-05-01 21:37 ` Brandeburg, Jesse
2009-05-01 8:29 ` [PATCH] net: skb_tx_hash() improvements Eric Dumazet
2009-05-01 8:52 ` Eric Dumazet
2009-05-01 9:29 ` Eric Dumazet
2009-05-01 16:17 ` David Miller
2009-05-03 21:44 ` David Miller
2009-05-04 6:12 ` Eric Dumazet
2009-05-01 16:08 ` tx queue hashing hot-spots and poor performance (multiq, ixgbe) David Miller
2009-05-01 16:48 ` Eric Dumazet
2009-05-01 17:22 ` David Miller
2009-05-01 10:20 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090430.022417.07019547.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=andrew@whydna.net \
--cc=jelaas@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.