netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Niklas Cassel <niklas.cassel@axis.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "edumazet@google.com" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: network stream fairness
Date: Mon, 9 Nov 2015 16:53:02 +0100	[thread overview]
Message-ID: <5640C15E.805@axis.com> (raw)
In-Reply-To: <1447084258.17135.39.camel@edumazet-glaptop2.roam.corp.google.com>

On 11/09/2015 04:50 PM, Eric Dumazet wrote:
> On Mon, 2015-11-09 at 16:41 +0100, Niklas Cassel wrote:
>> I have a ethernet driver for a 100 Mbps NIC.
>> The NIC has dedicated hardware for offloading.
>> The driver has implemented TSO, GSO and BQL.
>> Since the CPU on the SoC is rather weak, I'd rather
>> not increase the CPU load by turning off offloading.
>>
>> Since commit
>> 605ad7f184b6 ("tcp: refine TSO autosizing")
>>
>> the bandwidth is no longer fair between streams.
>> see output at the end of the mail, where I'm testing with 2 streams.
>>
>>
>> If I revert 605ad7f184b6 on 4.3, I get a stable 45 Mbps per stream.
>>
>> I can also use vanilla 4.3 and do:
>> echo 3000 > /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max
>> to also get a stable 45 Mbps per stream.
>>
>> My question is, am I supposed to set the BQL limit explicitly?
>> It is possible that I have missed something in my driver,
>> but my understanding is that the TCP stack sets and adjusts
>> the BQL limit automatically.
>>
>>
>> Perhaps the following info might help:
>>
>> After running iperf3 on vanilla 4.3:
>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/
>> limit 89908
>> limit_max 1879048192
>>
>> After running iperf3 on vanilla 4.3 + BQL explicitly set:
>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/
>> limit 3000
>> limit_max 3000
>>
>> After running iperf3 on 4.3 + 605ad7f184b6 reverted:
>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/
>> limit 8886
>> limit_max 1879048192
>>
> 
> There is absolutely nothing ensuring fairness among multiple TCP flows.
> 
> One TCP flow can very easily grab whole bandwidth for itself, there are
> numerous descriptions of this phenomena in various TCP studies. 
> 
> This is why we have packet schedulers ;)

Oh.. How stupid of me, I forgot to mention.. all of the measurements were
done with fq_codel.

> 
> tc qdisc replace dev eth0 root fq
> 
> This will probably help : No need to change BQL settings, so that you
> keep minimal latencies for the interactive traffic (like ping)
> 
> 
> 
> 

  reply	other threads:[~2015-11-09 15:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-09 15:41 network stream fairness Niklas Cassel
2015-11-09 15:50 ` Eric Dumazet
2015-11-09 15:53   ` Niklas Cassel [this message]
2015-11-09 16:07     ` Eric Dumazet
2015-11-09 16:24       ` Eric Dumazet
2015-11-09 16:50         ` Niklas Cassel
2015-11-09 17:23           ` Eric Dumazet
2015-11-10  9:38             ` Niklas Cassel
2015-11-20 15:33       ` Niklas Cassel
2015-11-20 18:16         ` Eric Dumazet
2015-11-25 12:47           ` Niklas Cassel
2015-11-25 13:49             ` Eric Dumazet
2015-11-29  2:41               ` Niklas Cassel
2015-11-29 17:40                 ` 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=5640C15E.805@axis.com \
    --to=niklas.cassel@axis.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).