netdev - Re: [PATCH net-next v4 1/2] net: sched: pie: refactor code

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: <CAHv+uoF82nKrFLRKdP+fCVkc9Kay2dBRZz3hXJoRQWy6c387Tg@mail.gmail.com>
Date:   Fri, 17 Jan 2020 22:29:34 +0530
From:   Leslie Monis <lesliemonis@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Gautam Ramakrishnan <gautamramk@...il.com>,
        Linux NetDev <netdev@...r.kernel.org>,
        "Mohit P. Tahiliani" <tahiliani@...k.edu.in>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        "David S . Miller" <davem@...emloft.net>,
        Dave Taht <dave.taht@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        "Sachin D . Patil" <sdp.sachin@...il.com>,
        "V . Saicharan" <vsaicharan1998@...il.com>,
        Mohit Bhasi <mohitbhasi1998@...il.com>
Subject: Re: [PATCH net-next v4 1/2] net: sched: pie: refactor code

On Fri, Jan 17, 2020 at 9:26 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> gautamramk@...il.com writes:
>
> > From: "Mohit P. Tahiliani" <tahiliani@...k.edu.in>
> >
> > This patch is a precursor for the addition of the Flow Queue Proportional
> > Integral Controller Enhanced (FQ-PIE) qdisc. The patch removes structures
> > and small inline functions common to both PIE and FQ-PIE and moves it to
> > the header file include/net/pie.h. It also exports symbols from sch_pie.c
> > that are to be reused in sch_fq_pie.c.
>
> The way this is done means that sch_fq_pie.ko will end up with a module
> dependency on sch_pie.ko, right?

Yes, we did make sch_fq_pie.ko dependent on sch_pie.ko in this series.
We thought of doing this when we started out, but later on decided to
follow something similar to the codel - fq_codel implementation.

> I don't think we have any such
> dependencies already; not *necessarily* a blocker, but it does strike me
> as a bit odd.

Yes, no existing qdiscs have dependencies, except for sch_atm and
sch_ingress.

Leslie