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 19:28:40 +0200 [thread overview]
Message-ID: <20141001192840.5679a671@redhat.com> (raw)
In-Reply-To: <542C1F1F.90404@mojatatu.com>
On Wed, 01 Oct 2014 11:34:55 -0400 Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> The issue is: if i am going to attempt to do a bulk transfer
> every single time (with new code) and for the common use case the
> result is "no need to do bulking" then you just added extra code that
> is unnecessary for that common case.
> Even a single extra if statement at high packet rate is still
> costly and would be easy to observe.
[...]
>
> That is if the added code ends up being hit
> meaningfully. Jesper said (and it was my experience as well)
> that it was _hard_ to achieve bulking in such a case.
Let me close this one...
The bulk dequeue code *is* being hit meaningfully. It is _only_ going
to be activated when (q->qlen > 0) see __dev_xmit_skb() in dev.c.
When there is no queue pfifo_fast is allowed to directly call
sch_direct_xmit() without a enqueue/dequeue cycle. Thus, this code
would not be hit for every packet.
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:
"Subject: qdisc/UDP_STREAM: measuring effect of qdisc bulk dequeue"
http://thread.gmane.org/gmane.linux.network/331152/focus=331154
I actually believe, that I have already measured and shown that going
though the bulk dequeue is a win, this should show direct_xmit vs.
bulking:
"Subject: qdisc/trafgen: Measuring effect of qdisc bulk dequeue, with trafgen"
http://thread.gmane.org/gmane.linux.network/331152
--
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 17:29 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 [this message]
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=20141001192840.5679a671@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.