From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Michel Machado <michel@digirati.com.br>,
Nishanth Devarajan <ndev2021@gmail.com>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jiri Pirko <jiri@resnulli.us>, David Miller <davem@davemloft.net>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Cody Doucette <doucette@bu.edu>
Subject: Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
Date: Fri, 13 Jul 2018 10:00:12 -0300 [thread overview]
Message-ID: <20180713130012.GI8880@localhost.localdomain> (raw)
In-Reply-To: <CAM_iQpU6rsFEF9hHcN7JUqgtQvX9bR=teW6nCHMdoW_UJ8KSZw@mail.gmail.com>
On Thu, Jul 12, 2018 at 10:07:30PM -0700, Cong Wang wrote:
> On Wed, Jul 11, 2018 at 11:37 AM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Tue, Jul 10, 2018 at 07:32:43PM -0700, Cong Wang wrote:
> > > On Mon, Jul 9, 2018 at 12:53 PM Marcelo Ricardo Leitner
> > > <marcelo.leitner@gmail.com> wrote:
> > > >
> > > > On Mon, Jul 09, 2018 at 02:18:33PM -0400, Michel Machado wrote:
> > > > >
> > > > > 2. sch_prio.c does not have a global limit on the number of packets on
> > > > > all its queues, only a limit per queue.
> > > >
> > > > It can be useful to sch_prio.c as well, why not?
> > > > prio_enqueue()
> > > > {
> > > > ...
> > > > + if (count > sch->global_limit)
> > > > + prio_tail_drop(sch); /* to be implemented */
> > > > ret = qdisc_enqueue(skb, qdisc, to_free);
> > > >
> > >
> > > Isn't the whole point of sch_prio offloading the queueing to
> > > each class? If you need a limit, there is one for each child
> > > qdisc if you use for example pfifo or bfifo (depending on you
> > > want to limit bytes or packets).
> >
> > Yes, but Michel wants to drop from other lower priorities if needed,
> > and that's not possible if you handle the limit already in a child
> > qdisc as they don't know about their siblings. The idea in the example
> > above is to discard it from whatever lower priority is needed, then
> > queue it. (ok, the example missed to check the priority level)
>
> So it disproves your point of adding a flag to sch_prio, right?
I don't see how?
>
> Also, you have to re-introduce qdisc->ops->drop() if you really want
> to go this direction.
Again, yes. What's the deal with it?
>
> >
> > As for the different units, sch_prio holds a count of how many packets
> > are queued on its children, and that's what would be used for the limit.
> >
> > >
> > > Also, what's your plan for backward compatibility here?
> >
> > say:
> > if (sch->global_limit && count > sch->global_limit)
> > as in, only do the limit check/enforcing if needed.
>
> Obviously doesn't work, users could pass 0 to effectively
> disable the qdisc from enqueue'ing any packet.
If you only had considered the right 'limit' variable, you would be
right here.
next prev parent reply other threads:[~2018-07-13 13:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-07 10:13 [PATCH v3 net-next] net/sched: add skbprio scheduler Nishanth Devarajan
2018-07-09 15:44 ` Marcelo Ricardo Leitner
2018-07-09 18:18 ` Michel Machado
2018-07-09 19:53 ` Marcelo Ricardo Leitner
2018-07-09 21:03 ` Michel Machado
2018-07-09 21:40 ` Marcelo Ricardo Leitner
2018-07-10 14:03 ` Michel Machado
2018-07-10 14:33 ` Marcelo Ricardo Leitner
2018-07-11 2:25 ` Cong Wang
2018-07-11 19:33 ` Marcelo Ricardo Leitner
2018-07-13 6:05 ` Cong Wang
2018-07-13 13:04 ` Marcelo Ricardo Leitner
2018-07-13 18:26 ` Cong Wang
2018-07-14 4:39 ` Marcelo Ricardo Leitner
2018-07-17 6:41 ` Cong Wang
2018-07-11 2:32 ` Cong Wang
2018-07-11 18:37 ` Marcelo Ricardo Leitner
2018-07-13 5:07 ` Cong Wang
2018-07-13 13:00 ` Marcelo Ricardo Leitner [this message]
2018-07-13 18:17 ` Cong Wang
2018-07-14 4:51 ` Marcelo Ricardo Leitner
2018-07-17 5:36 ` Cong Wang
2018-07-11 2:38 ` Cong Wang
2018-07-11 2:57 ` Cong Wang
2018-07-11 15:24 ` Michel Machado
2018-07-19 18:39 ` Cong Wang
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=20180713130012.GI8880@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=doucette@bu.edu \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=michel@digirati.com.br \
--cc=ndev2021@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.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 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).