From: Jamal Hadi Salim <jhs@mojatatu.com>
To: David Miller <davem@davemloft.net>
Cc: brouer@redhat.com, netdev@vger.kernel.org, therbert@google.com,
eric.dumazet@gmail.com, hannes@stressinduktion.org, fw@strlen.de,
dborkman@redhat.com, alexander.duyck@gmail.com,
john.r.fastabend@intel.com, dave.taht@gmail.com, toke@toke.dk
Subject: Re: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
Date: Wed, 01 Oct 2014 09:17:39 -0400 [thread overview]
Message-ID: <542BFEF3.7020302@mojatatu.com> (raw)
In-Reply-To: <20140930.142038.235338672810639160.davem@davemloft.net>
On 09/30/14 14:20, David Miller wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
> Date: Tue, 30 Sep 2014 07:07:37 -0400
>
>> Note, there are benefits as you have shown - but i would not
>> consider those to be standard use cases (actully one which would
>> have shown clear win is the VM thing Rusty was after).
>
> I completely disagree, you will see at least decreased cpu utilization
> for a very common case, bulk single stream transfers.
>
So lets say the common use case is:
= modern day cpu (pick some random cpu)
= 1-10 Gbps ethernet (not 100mbps)
= 1-24 tcp or udp bulk (you said one, Jesper had 24 which sounds better)
Run with test cases:
a) unchanged (no bulking code added at all)
vs
b) bulking code added and used
vs
c) bulking code added and *not* used
Jesper's results are comparing #b and #c.
And if #b + #c are slightly worse or equal then we have a win;->
Again, I do believe things like traffic generators or the VM io
or something like tuntap that crosses user space will have a clear
benefit (but are those common use cases?).
cheers,
jamal
next prev parent reply other threads:[~2014-10-01 13:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 8:53 [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE Jesper Dangaard Brouer
2014-09-30 11:07 ` Jamal Hadi Salim
2014-09-30 18:20 ` David Miller
2014-10-01 13:17 ` Jamal Hadi Salim [this message]
2014-10-01 14:55 ` Tom Herbert
2014-10-01 15:34 ` Jamal Hadi Salim
2014-10-01 17:28 ` Jesper Dangaard Brouer
2014-10-01 18:55 ` Jamal Hadi Salim
2014-10-01 19:47 ` Jesper Dangaard Brouer
2014-10-01 20:05 ` Jamal Hadi Salim
2014-10-01 20:32 ` Jesper Dangaard Brouer
2014-10-02 5:18 ` Dave Taht
2014-10-02 7:44 ` Jesper Dangaard Brouer
2014-10-02 10:08 ` Toke Høiland-Jørgensen
2014-10-02 13:02 ` Jamal Hadi Salim
2014-10-02 12:53 ` Jamal Hadi Salim
2014-10-01 19:47 ` David Miller
2014-09-30 11:48 ` Eric Dumazet
2014-09-30 12:25 ` Florian Westphal
2014-09-30 12:38 ` Eric Dumazet
2014-09-30 12:41 ` Florian Westphal
2014-09-30 22:07 ` Jesper Dangaard Brouer
2014-09-30 22:15 ` Eric Dumazet
2014-09-30 12:34 ` Eric Dumazet
2014-09-30 12:51 ` [net-next PATCH] dql: add a burst attribute Eric Dumazet
2014-09-30 13:46 ` Florian Westphal
2014-09-30 14:17 ` Eric Dumazet
2014-09-30 14:26 ` Tom Herbert
2014-09-30 14:49 ` Eric Dumazet
2014-09-30 15:05 ` Tom Herbert
2014-09-30 14:31 ` Florian Westphal
2014-09-30 14:55 ` Eric Dumazet
2014-09-30 21:46 ` Jesper Dangaard Brouer
2014-10-01 4:44 ` Tom Herbert
2014-09-30 15:26 ` Florian Westphal
2014-09-30 15:39 ` Dave Taht
2014-09-30 15:41 ` Eric Dumazet
2014-09-30 21:29 ` 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=542BFEF3.7020302@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=alexander.duyck@gmail.com \
--cc=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=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.