From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: "Tom Herbert" <therbert@google.com>,
"David Miller" <davem@davemloft.net>,
"Linux Netdev List" <netdev@vger.kernel.org>,
"Eric Dumazet" <eric.dumazet@gmail.com>,
"Hannes Frederic Sowa" <hannes@stressinduktion.org>,
"Florian Westphal" <fw@strlen.de>,
"Daniel Borkmann" <dborkman@redhat.com>,
"Alexander Duyck" <alexander.duyck@gmail.com>,
"John Fastabend" <john.r.fastabend@intel.com>,
"Dave Taht" <dave.taht@gmail.com>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
brouer@redhat.com
Subject: Re: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE
Date: Wed, 1 Oct 2014 21:47:00 +0200 [thread overview]
Message-ID: <20141001214700.18b16387@redhat.com> (raw)
In-Reply-To: <542C4E0D.4050404@mojatatu.com>
On Wed, 01 Oct 2014 14:55:09 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 10/01/14 13:28, Jesper Dangaard Brouer wrote:
>
> > Thus, code is activated only when q->qlen is >= 1. And I have already
> > shown that we see a win with just bulking 2 packets:
>
> If you can get 2 packets, indeed you win. If you can on average get >1
> over a long period, you still win.
> You have clearly demonstrated you can do that with traffic
> generators (udp or in kernel pktgen). I was more worried about the
> common use case scenario (handwaved as 1-24 TCP streams).
>
> The key here is: *if you never hit bulking* then the cost is
> _per packet_ for sch_direct_xmit bypass.
> Question is what is that cost for the common case as defined above?
> Can you hit a bulk level >1 on 1-24 TCP streams?
> I would be happy if your answer is *yes*.
Answer is yes. It is very easy with simple netperf TCP_STREAM to cause
queueing >1 packet in the qdisc layer. If tuned (according to my blog,
unloading netfilter etc.) then a single netperf TCP_STREAM will max out
10Gbit/s and cause a standing queue.
I'm monitoring backlog of qdiscs, and I always see >1 backlog, I never
saw a standing queue of 1 packet in my testing. Either the backlog
area is high 100-200 packets, or 0 backlog. (With fake pktgen/trafgen
style tests, it's possible to cause 1000 backlog).
> If your answer is no (since
> it is hard to achieve) - then how far off is it from before your
> patches (since now you have added at minimal a branch check).
> I think it is fair for you to quantify that, no?
> Feature is still useful for the other cases.
>
> Note:
> This is what i referred to as the "no animals were hurt during the
> making of these patches" statement. I am sorry again for raining on
> the parade.
I'm starting to think this patch is the most carefully tested patch on
netdev for a very very long time... I'm getting tired of this testing
going on for so long.
--
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-10-01 19:47 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
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 [this message]
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=20141001214700.18b16387@redhat.com \
--to=brouer@redhat.com \
--cc=alexander.duyck@gmail.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 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.