netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Tom Herbert <therbert@google.com>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Daniel Borkmann <dborkman@redhat.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	John Fastabend <john.r.fastabend@intel.com>,
	Dave Taht <dave.taht@gmail.com>,
	toke@toke.dk
Subject: Re: [net-next PATCH] dql: add a burst attribute
Date: Tue, 30 Sep 2014 17:26:51 +0200	[thread overview]
Message-ID: <20140930152651.GC24565@breakpoint.cc> (raw)
In-Reply-To: <1412086646.30721.81.camel@edumazet-glaptop2.roam.corp.google.com>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-30 at 15:46 +0200, Florian Westphal wrote:
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > From: Eric Dumazet <edumazet@google.com>
> > > 
> > > Add a new dql attribute, to control how much packets we are allowed to
> > > burst from qdisc to device.
> > 
> > I understand the motivation for this, but I find it a bit out-of-place
> > to have a 'packet' type counter in bql context?
> > 
> > Would it perhaps make more sense to restrict bulk dequeues by an upper
> > (possibly changeable from userspace) byte counter limit?
> 
> The byte count is already provided : its the BQL limit.
> We already have ways to tune it (limit_min & limit_max)
> We do not think we need something else here.

So you're saying that a bulk dequeue should just grab as many skbs
as possible until no more available or dql_avail exhausted?

The "magic" value was just to be conservative and not induce any
hol blocking, which is also why Jesper reduced it again in the latest
submission.

Then, we might later be able to remove the TSO restriction and switch
to a pure byte-based limit.

(I don't think having a packet-based count makes sense once tso/gso
 skbs can be bulk dequeued).

Sorry for the confusion.

  parent reply	other threads:[~2014-09-30 15:26 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
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 [this message]
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=20140930152651.GC24565@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexander.duyck@gmail.com \
    --cc=brouer@redhat.com \
    --cc=dave.taht@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --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 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).