From: Rick Jones <rick.jones2@hpe.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev <netdev@vger.kernel.org>, Alexander Duyck <aduyck@mirantis.com>
Subject: Re: [RFC] net: remove busylock
Date: Thu, 19 May 2016 11:41:39 -0700 [thread overview]
Message-ID: <573E08E3.3020200@hpe.com> (raw)
In-Reply-To: <CAKgT0UfBxW=KpqJux+tjyNpHQUHhZ5Laiqnt5FPs=jpkBJWrHA@mail.gmail.com>
On 05/19/2016 11:03 AM, Alexander Duyck wrote:
> On Thu, May 19, 2016 at 10:08 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> With HTB qdisc, here are the numbers for 200 concurrent TCP_RR, on a host with 48 hyperthreads.
...
>>
>> That would be a 8 % increase.
>
> The main point of the busy lock is to deal with the bulk throughput
> case, not the latency case which would be relatively well behaved.
> The problem wasn't really related to lock bouncing slowing things
> down. It was the fairness between the threads that was killing us
> because the dequeue needs to have priority.
Quibbledrift... While the origins of the netperf TCP_RR test center on
measuring latency, I'm not sure I'd call 200 of them running
concurrently a latency test. Indeed it may be neither fish nor fowl,
but it will certainly be exercising the basic packet send/receive path
rather fully and is likely a reasonable proxy for aggregate small packet
performance.
happy benchmarking,
rick jones
next prev parent reply other threads:[~2016-05-19 18:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 17:08 [RFC] net: remove busylock Eric Dumazet
2016-05-19 18:03 ` Alexander Duyck
2016-05-19 18:41 ` Rick Jones [this message]
2016-05-19 18:56 ` Eric Dumazet
2016-05-19 19:35 ` Eric Dumazet
2016-05-19 20:39 ` Alexander Duyck
2016-05-20 4:49 ` John Fastabend
2016-05-20 4:56 ` Eric Dumazet
2016-05-20 7:29 ` Jesper Dangaard Brouer
2016-05-20 13:11 ` Eric Dumazet
2016-05-20 13:47 ` Eric Dumazet
2016-05-20 14:16 ` Eric Dumazet
2016-05-20 17:49 ` Jesper Dangaard Brouer
2016-05-20 21:32 ` Eric Dumazet
2016-05-23 9:50 ` Jesper Dangaard Brouer
2016-05-23 21:24 ` [PATCH net] net_sched: avoid too many hrtimer_start() calls Eric Dumazet
2016-05-24 21:49 ` David Miller
2016-05-24 13:50 ` [RFC] net: remove busylock David Laight
2016-05-24 14:37 ` Eric Dumazet
2016-05-20 16:01 ` John Fastabend
2016-05-19 18:12 ` David Miller
2016-05-19 18:44 ` Eric Dumazet
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=573E08E3.3020200@hpe.com \
--to=rick.jones2@hpe.com \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/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).