From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Jesper Dangaard Brouer' <brouer@redhat.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
netdev <netdev@vger.kernel.org>,
Alexander Duyck <aduyck@mirantis.com>,
John Fastabend <john.r.fastabend@intel.com>,
Jamal Hadi Salim <jhs@mojatatu.com>
Subject: Re: [RFC] net: remove busylock
Date: Tue, 24 May 2016 07:37:26 -0700 [thread overview]
Message-ID: <1464100646.5939.50.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F4C5166@AcuExch.aculab.com>
On Tue, 2016-05-24 at 13:50 +0000, David Laight wrote:
> From: Jesper Dangaard Brouer
> > Sent: 20 May 2016 18:50
> ...
> > If would be cool if you could run a test with removed busylock and
> > allow HTB to bulk dequeue.
>
> (Without having looked ....)
> Could you have two queues and separate queue and dequeue locks.
>
> The enqueue code would acquire the enqueue lock and add the packet
> to the first queue.
>
> The dequeue code would acquire the dequeue lock and try to remove
> a packet from the 2nd queue, if nothing present it would acquire
> the enqueue lock and move the entire 1st queue to the 2nd queue.
>
> The obvious downside is two lock/unlocks for single packet dequeue.
> If you can guarantee a single dequeue thread the 2nd lock isn't needed.
>
Not with HTB or any 'complex' qdisc hierarchy, where we have many
'queues' and strict limits (packets per qdisc)
next prev parent reply other threads:[~2016-05-24 14:37 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
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 [this message]
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=1464100646.5939.50.camel@edumazet-glaptop3.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=aduyck@mirantis.com \
--cc=alexander.duyck@gmail.com \
--cc=brouer@redhat.com \
--cc=jhs@mojatatu.com \
--cc=john.r.fastabend@intel.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 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.