From: Bill Fink <billfink@mindspring.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Yevgeny Petrilin <yevgenyp@mellanox.com>,
David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next 1/3] mlx4_en: TX ring size default to 1024
Date: Sat, 25 Feb 2012 01:51:22 -0500 [thread overview]
Message-ID: <20120225015122.a7419f74.billfink@mindspring.com> (raw)
In-Reply-To: <1330114654.2596.3.camel@edumazet-laptop>
On Fri, 24 Feb 2012, Eric Dumazet wrote:
> Le vendredi 24 février 2012 à 19:35 +0000, Yevgeny Petrilin a écrit :
> > > > Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> > >
> > > This is rediculious as a default, yes even for 10Gb.
> > >
> > > Do you have any idea how high latency is going to be for packets
> > > trying to get into the transmit queue if there are already a
> > > thousand other frames in there?
For a GigE NIC with a typical ring size of 256, the serialization delay
for 256 1500 byte packets is:
1500*8*256/10^9 = ~3.1 msec
For a 10-GigE NIC with a ring size of 1024, the serialization delay
for 1024 1500 byte packets is:
1500*8*1024/10^10 = ~1.2 msec
So it's not immediately clear that a ring size of 1024 is unreasonable
for 10-GigE.
It probably boils down to whether the default setting should
be biased more toward low latency applications or high throughput
bulk data applications. Determining the best happy medium is
best decided by appropriate benchmark testing. Of course,
anyone can change the settings to suit their purpose, so it's
really just a question of what's best for the "usual" case.
> > On the other hand, when having smaller queue with 1000 in-flight packets would mean queue would be stopped,
> > how is it better?
>
> Its better because you can have any kind of Qdisc setup to properly
> classify packets, with 100.000 total packets in queues if you wish.
Not everyone wants to deal with the convoluted, arcane, and poorly
documented qdisc machinery, especially with its current limitations
at 10-GigE (or faster) line rates.
> TX ring is a single FIFO, and that is just horrible, especially with big packets...
>
> > Having bigger TX ring helps dealing better with bursts of TX packets, without the overhead of stopping and starting the queue,
> > It also makes sense to have same size TX and RX queues, for example in case of traffic being forwarded from TX to RX.
>
> Really I doubt people using forwarding setups use default qdiscs.
I don't think it's necessarily that uncommon, such as a simple
10-GigE firewall setup.
> Instead of bigger TX rings, they need appropriate Qdiscs.
>
> > I did find number of 10Gb vendors that have 1024 or more as the default size for TX queue.
>
> Thats a shame.
-Bill
next prev parent reply other threads:[~2012-02-25 6:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 13:34 [PATCH net-next 1/3] mlx4_en: TX ring size default to 1024 Yevgeny Petrilin
2012-02-23 19:45 ` David Miller
2012-02-23 19:54 ` Eric Dumazet
2012-02-24 19:35 ` Yevgeny Petrilin
2012-02-24 20:14 ` David Miller
2012-02-24 20:17 ` Eric Dumazet
2012-02-25 6:51 ` Bill Fink [this message]
2012-02-25 8:22 ` Eric Dumazet
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=20120225015122.a7419f74.billfink@mindspring.com \
--to=billfink@mindspring.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=yevgenyp@mellanox.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox