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: Sat, 14 Jul 2018 01:51:02 -0300
Message-ID: <20180714045101.GB20383@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>
 <20180713130012.GI8880@localhost.localdomain>
 <CAM_iQpXYYEnsKwEwmRT4WPErByhv-UzO4XanpRPZQkYpZpU7Rg@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-qk0-f196.google.com ([209.85.220.196]:37084 "EHLO
        mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1725851AbeGNFIn (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sat, 14 Jul 2018 01:08:43 -0400
Received: by mail-qk0-f196.google.com with SMTP id t79-v6so18237423qke.4
        for <netdev@vger.kernel.org>; Fri, 13 Jul 2018 21:51:05 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAM_iQpXYYEnsKwEwmRT4WPErByhv-UzO4XanpRPZQkYpZpU7Rg@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Fri, Jul 13, 2018 at 11:17:18AM -0700, Cong Wang wrote:
...
> > > > > 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?
> 
> Interesting, you said "Michel wants to drop from other lower
> priorities if needed", but sch_prio has no knowledge of this,
> you confirmed with "...if you handle the limit already in a child
> qdisc as they don't know about their siblings."
> 
> The if clause is true as the limit is indeed handled by its child
> qdiscs as designed.
> 
> Therefore, a simple of adding a flag to sch_prio, as you
> suggested and demonstrated above, doesn't work, as
> confirmed by your own words.

Well, it would help if you didn't cut out key parts of my words.

> 
> What am I missing here?
> 
> Are you go further by suggesting moving the limit out of prio?
> Or are you going to expand your definition of "adding a flag"?
> Perhaps two flags? :)
> 
> I am very open for discussion to see how far we can go.

I am not keen on continuing this discussion if you keep twisting my
words just for fun.