netdev - Re: [PATCH v3 net-next] net/sched: add skbprio scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpXYYEnsKwEwmRT4WPErByhv-UzO4XanpRPZQkYpZpU7Rg@mail.gmail.com>
Date:   Fri, 13 Jul 2018 11:17:18 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc:     Michel Machado <michel@...irati.com.br>,
        Nishanth Devarajan <ndev2021@...il.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Cody Doucette <doucette@...edu>
Subject: Re: [PATCH v3 net-next] net/sched: add skbprio scheduler

On Fri, Jul 13, 2018 at 6:00 AM Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
>
> 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@...il.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@...il.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?

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.

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.

>
> >
> > 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?
>

Nothing, just want to tell you ops->drop() is nothing new, to help
your discussion.


> >
> > >
> > > 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.

Yeah, that is exactly what you propose, isn't it? :)

Thanks!