From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Tom Herbert <therbert@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Florian Westphal <fw@strlen.de>,
Daniel Borkmann <dborkman@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
John Fastabend <john.r.fastabend@intel.com>
Subject: Re: [RFC net-next PATCH V2 0/3] qdisc bulk dequeuing and utilizing delayed tailptr updates
Date: Thu, 04 Sep 2014 09:44:05 -0400 [thread overview]
Message-ID: <54086CA5.6040209@mojatatu.com> (raw)
In-Reply-To: <20140904125247.4108.8132.stgit@dragon>
On 09/04/14 08:54, Jesper Dangaard Brouer wrote:
> Wanted people to review this work early... so this is the current
> state, even added my debug patch, if people want to "see" it work.
>
It would be useful to collect some stats when you are
experimenting with this stuff on the average batch size the driver
sees. Maybe a histogram which shows >1, > 3, > 10 etc that a
driver was able to chew on at a time. I realize this may skew
your results a little because you have to chew cycles updating
such a histogram.
I believe that any dumb traffic generator will show lots of packets
being batched. But that is not very interesting.
It would be hard to show more than 1 in the general case for
other types of traffic - but learning what else needs to be tweaked
to achive more batch sizes would be helpful.
i.e this would help quantify whether the batching is valuable in the
general sense...
cheers,
jamal
prev parent reply other threads:[~2014-09-04 13:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 12:54 [RFC net-next PATCH V2 0/3] qdisc bulk dequeuing and utilizing delayed tailptr updates Jesper Dangaard Brouer
2014-09-04 12:54 ` [RFC net-next PATCH V2 1/3] net: Functions to report space available in device TX queues Jesper Dangaard Brouer
2014-09-04 12:55 ` [RFC net-next PATCH V2 2/3] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE Jesper Dangaard Brouer
2014-09-04 13:17 ` Florian Westphal
2014-09-04 17:09 ` Cong Wang
2014-09-04 13:29 ` Eric Dumazet
2014-09-05 8:28 ` Jesper Dangaard Brouer
2014-09-06 12:55 ` Eric Dumazet
2014-09-04 16:59 ` Tom Herbert
2014-09-04 12:56 ` [RFC net-next PATCH V2 3/3] qdisc: debug statements while testing prev-patch Jesper Dangaard Brouer
2014-09-04 13:44 ` Jamal Hadi Salim [this message]
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=54086CA5.6040209@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=alexander.duyck@gmail.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=hannes@stressinduktion.org \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/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.