All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: "Eric Dumazet" <eric.dumazet@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Tom Herbert" <therbert@google.com>,
	"David Miller" <davem@davemloft.net>,
	"Hannes Frederic Sowa" <hannes@stressinduktion.org>,
	"Daniel Borkmann" <dborkman@redhat.com>,
	"Florian Westphal" <fw@strlen.de>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Dave Taht" <dave.taht@gmail.com>
Subject: Re: Qdisc: Measuring Head-of-Line blocking with netperf-wrapper
Date: Tue, 16 Sep 2014 15:22:21 +0200	[thread overview]
Message-ID: <20140916152221.41811287@redhat.com> (raw)
In-Reply-To: <20140915184517.6c5474e5@redhat.com>

On Mon, 15 Sep 2014 18:45:17 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:

> I've constructed a "netperf-wrapper" test for measuring Head-of-Line
> blocking, called "tcp_upload_prio", that I hope you will approve of?
> 
>  https://github.com/tohojo/netperf-wrapper/commit/1e6b755e8051b6
> 
> The basic idea is to have ping packets with TOS bit 0x10, which end-up
> in the high-prio band of pfifo_fast.  While two TCP uploads utilize
> all the bandwidth.
> 
> These high-prio ping packet should then demonstrate the Head-of-Line
> blocking occurring due to 1) packets in the HW TX ring buffer, or
> 2) in the qdisc layers requeue mechanism.  Disgusting these two case
> might be a little difficult.

Let me demonstrate some the results with some graphs. I'm comparing
same kernel (net-next at c0d1379a) with different TSO, GSO and
disabled-TSO+GSO:

Test TYPES are:
- TSO     == ethtool -K eth4 gro on  gso on  tso on
- GSO     == ethtool -K eth4 gro on  gso on  tso off
- NoneXSO == ethtool -K eth4 gro off gso off tso off

A ping graph for with TSO enabled looks like:
 http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__ping--TSO_net_next.png

- It clearly shows that we can measure the difference between the
  best-effort and high-priority ping packets.


Zooming in on high-prio ping only, and comparing TSO vs GSO:
 http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_hiprio.png
 http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_cdf.png

- It clearly shows that GSO have lower/better ping values that TSO,
  e.g. smaller HoL blocking


When adding the NoneXSO to the high-prio compare:
 http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO_vs_NoneXSO__ping_hiprio.png
 http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO_vs_NoneXSO__ping_cdf.png

- Then it look a little strange, because the none-GSO/TSO setting looks
  like it have larger Head-of-Line blocking delays.  Something I was
  not expecting.

Do notice that the NoneXSO case have a lower overall/average latency,
likely due to 1) TSO and GSO can put more "bytes" into the qdisc's 1000
packet limit, 2) NoneXSO have more difficulties exausting all
bandwidth, see graph:
 http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__totals--NoneXSO_net_next.png
vs a more stable TCP speeds with GSO:
 http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__totals--GSO_net_next.png

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

  parent reply	other threads:[~2014-09-16 13:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 16:45 Qdisc: Measuring Head-of-Line blocking with netperf-wrapper Jesper Dangaard Brouer
2014-09-15 17:10 ` Tom Herbert
2014-09-15 17:24   ` Eric Dumazet
2014-09-15 18:55     ` Dave Taht
2014-09-15 19:12       ` Rick Jones
2014-09-16  6:30     ` Jesper Dangaard Brouer
2014-09-16 15:52       ` Tom Herbert
2014-09-16 13:22 ` Jesper Dangaard Brouer [this message]
2014-09-16 13:59   ` Eric Dumazet
2014-09-16 15:56     ` Jesper Dangaard Brouer
2014-09-16 16:08       ` Dave Taht
2014-09-16 16:30       ` Eric Dumazet
2014-09-17  7:39         ` Jesper Dangaard Brouer

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=20140916152221.41811287@redhat.com \
    --to=brouer@redhat.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=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.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.