From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: "Tom Herbert" <therbert@google.com>,
"Jamal Hadi Salim" <jhs@mojatatu.com>,
"Eric Dumazet" <eric.dumazet@gmail.com>,
"Linux Netdev List" <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
"Alexander Duyck" <alexander.h.duyck@intel.com>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
"Florian Westphal" <fw@strlen.de>,
"Dave Taht" <dave.taht@gmail.com>,
"John Fastabend" <john.r.fastabend@intel.com>,
"Daniel Borkmann" <dborkman@redhat.com>,
"Hannes Frederic Sowa" <hannes@stressinduktion.org>
Subject: Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
Date: Mon, 29 Sep 2014 22:14:31 +0200 [thread overview]
Message-ID: <20140929221431.3e322aab@redhat.com> (raw)
In-Reply-To: <20140925172329.7460f787@redhat.com>
On Thu, 25 Sep 2014 17:23:29 +0200 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> I will redo the tests, once I get home to my testlab, as the remote lab
> I'm using now is annoyingly slow rebooting machines, as we not longer
> have a runtime option for enable/disable (I'm currently in Switzerland).
I'm going to change the bulking "budget" from 8 packet to 7 packets,
based on my netperf-wrapper test.
I've designed some tests for the tool "netperf-wrapper" that tries to
measure the HoL blocking effect. I've turned down the link speed to
100Mbit/s on driver igb. And uses a single TXQ setup
(cmdline: ethtool -L eth1 combined 1).
I can now show some kind of HoL blocking effect. The strange part is
the HoL effect only occurs above 8 packets, 7 packet and below show no
bad effect of this bulking patch.
Results 100Mbit/s test qdisc_prio_hol, latency in high prio band:
* GSO: stable average on 2.23ms
* TSO: varies between min 4.13ms to 4.41ms (range 0.28ms)
* No bulking: stable average on 1.71ms (3x outliners on 1.95ms)
* Bulking(8): varies between 1.71ms to 1.95ms (range 0.24ms)
* Bulking(7): stable average on 1.71ms (1x outliner on 1.95ms)
* Bulking(6): stable average on 1.71ms (3x outliners on 1.91ms)
* Bulking(5): stable average on 1.71ms (1x outliner on 1.91ms)
* Bulking(5): stable average on 1.71ms (1x outliner on 1.91ms)
* Bulking(4): stable average on 1.71ms (0x outliner)
Bulking(8) the calculation:
* Added delay were 0.24ms (1.95 - 1.71ms) corrosponding to 3000 bytes
* 1500 bytes *8 / 100Mbit = 0.12 ms
* (100*10^6)*(1.95/10^3)/8 = 24375 bytes
* (100*10^6)*(1.71/10^3)/8 = 21375 bytes
* Added HoL: 3000 bytes
* Still compared to TSO and GSO, the added HoL blocking is small.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2014-09-29 20:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 16:10 [net-next PATCH 0/1 V4] qdisc bulk dequeuing and utilizing delayed tailptr updates Jesper Dangaard Brouer
2014-09-24 16:12 ` [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE Jesper Dangaard Brouer
2014-09-24 17:23 ` Eric Dumazet
2014-09-24 17:58 ` Jesper Dangaard Brouer
2014-09-24 18:34 ` Tom Herbert
2014-09-24 19:22 ` Eric Dumazet
2014-09-25 2:12 ` Eric Dumazet
2014-09-25 2:38 ` Tom Herbert
2014-09-25 2:58 ` Dave Taht
2014-09-26 18:06 ` Eric Dumazet
2014-09-25 23:40 ` Eric Dumazet
2014-09-26 6:04 ` [PATCH net-next] dql: dql_queued() should write first to reduce bus transactions Eric Dumazet
2014-09-26 8:47 ` Jesper Dangaard Brouer
2014-09-26 11:06 ` Hannes Frederic Sowa
2014-09-26 12:02 ` Eric Dumazet
2014-09-28 21:43 ` David Miller
2014-09-26 9:23 ` [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE David Laight
2014-09-26 13:16 ` David Laight
2014-09-26 13:38 ` Eric Dumazet
2014-09-24 22:13 ` Jamal Hadi Salim
2014-09-25 8:25 ` Jesper Dangaard Brouer
2014-09-25 12:48 ` Jamal Hadi Salim
2014-09-25 14:40 ` Tom Herbert
2014-09-25 14:57 ` Jesper Dangaard Brouer
2014-09-25 15:05 ` Tom Herbert
2014-09-25 15:23 ` Jesper Dangaard Brouer
2014-09-25 15:58 ` Tom Herbert
2014-09-29 20:23 ` Jesper Dangaard Brouer
2014-09-29 20:14 ` Jesper Dangaard Brouer [this message]
2014-09-25 15:12 ` Eric Dumazet
2014-09-25 13:52 ` Dave Taht
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=20140929221431.3e322aab@redhat.com \
--to=brouer@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=hannes@stressinduktion.org \
--cc=jhs@mojatatu.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
--cc=toke@toke.dk \
/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).