From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [PATCH v3 net-next] net/sched: add skbprio scheduler
Date: Fri, 13 Jul 2018 10:00:12 -0300
Message-ID: <20180713130012.GI8880@localhost.localdomain>
References: <20180707101351.GA8300@gmail.com>
 <20180709154409.GC8880@localhost.localdomain>
 <b9f0e292-a29a-3c70-a215-cd6fc2ffbc6a@digirati.com.br>
 <20180709195319.GD8880@localhost.localdomain>
 <CAM_iQpUzkSdCzxCH5VxNEN=OyXNOXeiFUNGD-XwrbNptxyRkNA@mail.gmail.com>
 <20180711183755.GE8880@localhost.localdomain>
 <CAM_iQpU6rsFEF9hHcN7JUqgtQvX9bR=teW6nCHMdoW_UJ8KSZw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>
To: Cong Wang <xiyou.wangcong@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f194.google.com ([209.85.216.194]:44431 "EHLO
        mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728289AbeGMNOt (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 13 Jul 2018 09:14:49 -0400
Received: by mail-qt0-f194.google.com with SMTP id b15-v6so26928141qtp.11
        for <netdev@vger.kernel.org>; Fri, 13 Jul 2018 06:00:15 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAM_iQpU6rsFEF9hHcN7JUqgtQvX9bR=teW6nCHMdoW_UJ8KSZw@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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.