Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: John Fastabend <john.r.fastabend@intel.com>,
	Tom Herbert <therbert@google.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v4 0/10] bql: Byte Queue Limits
Date: Tue, 29 Nov 2011 15:57:47 +0100	[thread overview]
Message-ID: <1322578667.2465.13.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> (raw)
In-Reply-To: <CAA93jw6bvzASrtvjhKL+haZb0VEPvQQD0guf7aBTPxJbxydEAg@mail.gmail.com>

Le mardi 29 novembre 2011 à 09:51 +0100, Dave Taht a écrit :

> Perhaps I don't understand the gross effects of TSO very well, but if you have
> 100 streams coming from a server, destined to X different destinations,
> and you FQ to each on a per packet basis, you end up impacting the downstream
> receive buffers throughout much less than if you send each stream as a burst.

TSO makes packets larger, to lower cpu use in different layers (netfilter, qdisc, ...).

Imagine you could have MSS=65000 on your ethernet wire.

If you need to send a high prio packet while a prior big one is
in-flight on a dumb device (a single TX FIFO), there is nothing you
can do but wait last bit of big packet hit the wire.

Even with one flow you lose. Hundred flows dont matter
(as long as you have proper classification in Qdisc layer, of course)

Most setups dont care.

The ones caring dedicate a link for exclusive use, making sure it wont
cross loaded trunks. (Heartbeats in clusters)

Even disabling TSO wont be enough for them, if a single tcp flow can compete with them.

  reply	other threads:[~2011-11-29 14:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  2:32 [PATCH v4 0/10] bql: Byte Queue Limits Tom Herbert
2011-11-29  4:23 ` Dave Taht
2011-11-29  7:02   ` Eric Dumazet
2011-11-29  7:07     ` Eric Dumazet
2011-11-29  7:23     ` John Fastabend
2011-11-29  7:45       ` Eric Dumazet
2011-11-29  8:03         ` John Fastabend
2011-11-29  8:37       ` Dave Taht
2011-11-29  8:43         ` Eric Dumazet
2011-11-29  8:51           ` Dave Taht
2011-11-29 14:57             ` Eric Dumazet [this message]
2011-11-29 16:24               ` Dave Taht
2011-11-29 17:06                 ` David Laight
2011-11-29 14:24     ` Ben Hutchings
2011-11-29 14:29       ` Eric Dumazet
2011-11-29 16:06         ` Dave Taht
2011-11-29 16:41           ` Ben Hutchings
2011-11-29 17:28     ` Rick Jones
2011-11-29 16:46 ` Eric Dumazet
2011-11-29 17:47   ` David Miller
2011-11-29 18:31     ` Tom Herbert
2011-12-01 16:50       ` Kirill Smelkov
2011-12-01 18:00         ` David Miller
2011-12-02 11:22           ` Kirill Smelkov
2011-12-02 11:57             ` Eric Dumazet
2011-12-02 12:26               ` Kirill Smelkov

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=1322578667.2465.13.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC \
    --to=eric.dumazet@gmail.com \
    --cc=dave.taht@gmail.com \
    --cc=davem@davemloft.net \
    --cc=john.r.fastabend@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=therbert@google.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