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 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.