[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <542BFEF3.7020302@mojatatu.com>
Date: Wed, 01 Oct 2014 09:17:39 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: David Miller <davem@...emloft.net>
CC: brouer@...hat.com, netdev@...r.kernel.org, therbert@...gle.com,
eric.dumazet@...il.com, hannes@...essinduktion.org, fw@...len.de,
dborkman@...hat.com, alexander.duyck@...il.com,
john.r.fastabend@...el.com, dave.taht@...il.com, toke@...e.dk
Subject: Re: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with
TCQ_F_ONETXQUEUE
On 09/30/14 14:20, David Miller wrote:
> From: Jamal Hadi Salim <jhs@...atatu.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists