From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Tom Herbert <therbert@google.com>
Cc: "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>,
brouer@redhat.com
Subject: Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
Date: Thu, 25 Sep 2014 16:57:38 +0200 [thread overview]
Message-ID: <20140925165738.646d0783@redhat.com> (raw)
In-Reply-To: <CA+mtBx8Nie9AiCG6iuY+EN7HiLAe-bxWpZxTpRhASmYabRUyFA@mail.gmail.com>
On Thu, 25 Sep 2014 07:40:33 -0700
Tom Herbert <therbert@google.com> wrote:
> A few test results in patch 0 are good. I like to have results for
> with and without patch. These should two things: 1) Any regressions
> caused by the patch 2) Performance gains (in that order of importance
> :-) ). There doesn't need to be a lot here, just something reasonably
> representative, simple, and should be easily reproducible. My
> expectation in bulk dequeue is that we should see no obvious
> regression and hopefully an improvement in CPU utilization-- are you
> able to verify this?
We are saving 3% CPU, as I described in my post with subject:
"qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue":
http://thread.gmane.org/gmane.linux.network/331152/focus=331154
Using UDP_STREAM on 1Gbit/s driver igb, I can show that the
_raw_spin_lock calls are reduced with approx 3%, when enabling
bulking of just 2 packets.
This test can only demonstrates a CPU usage reduction, as the
throughput is already at maximum link (bandwidth) capacity.
Notice netperf option "-m 1472" which makes sure we are not sending
UDP IP-fragments::
netperf -H 192.168.111.2 -t UDP_STREAM -l 120 -- -m 1472
Results from perf diff::
# Command: perf diff
# Event 'cycles'
# Baseline Delta Symbol
# no-bulk bulk(1)
# ........ ....... .........................................
#
7.05% -3.03% [k] _raw_spin_lock
6.34% +0.23% [k] copy_user_enhanced_fast_string
6.30% +0.26% [k] fib_table_lookup
3.03% +0.01% [k] __slab_free
3.00% +0.08% [k] intel_idle
2.49% +0.05% [k] sock_alloc_send_pskb
2.31% +0.30% netperf [.] send_omni_inner
2.12% +0.12% netperf [.] send_data
2.11% +0.10% [k] udp_sendmsg
1.96% +0.02% [k] __ip_append_data
1.48% -0.01% [k] __alloc_skb
1.46% +0.07% [k] __mkroute_output
1.34% +0.05% [k] __ip_select_ident
1.29% +0.03% [k] check_leaf
1.27% +0.09% [k] __skb_get_hash
A nitpick is that, this testing were done on V2 of the patchset.
--
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-25 14:58 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 [this message]
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
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=20140925165738.646d0783@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).