netdev - Re: [PATCHv3 net-next] sched: add dualpi2 scheduler module

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]

Date:   Fri, 29 Mar 2019 13:57:36 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Olga Albisser <olgabnd@...il.com>, netdev@...r.kernel.org,
        Olga Albisser <olga@...isser.org>,
        Koen De Schepper <koen.de_schepper@...ia-bell-labs.com>,
        Oliver Tilmans <olivier.tilmans@...ia-bell-labs.com>,
        Bob Briscoe <research@...briscoe.net>,
        Henrik Steen <henrist@...rist.net>
Subject: Re: [PATCHv3 net-next] sched: add dualpi2 scheduler module

On Thu, 28 Mar 2019 02:35:38 -0700
Eric Dumazet <eric.dumazet@...il.com> wrote:

> >  obj-$(CONFIG_NET_SCH_ETF)	+= sch_etf.o
> >  obj-$(CONFIG_NET_SCH_TAPRIO)	+= sch_taprio.o
> > +obj-$(CONFIG_NET_SCH_DUALPI2)   += sch_dualpi2.o
> >  
> >  obj-$(CONFIG_NET_CLS_U32)	+= cls_u32.o
> >  obj-$(CONFIG_NET_CLS_ROUTE4)	+= cls_route.o
> > diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
> > new file mode 100644
> > index 000000000000..6b696a546492
> > --- /dev/null
> > +++ b/net/sched/sch_dualpi2.c
> > @@ -0,0 +4,691 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (C) 2018 Nokia.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.

The license boilerplate code is redundant and unnecessary with the
SPDX identifier.


> > + * Author: Koen De Schepper <koen.de_schepper@...ia-bell-labs.com>
> > + * Author: Olga Albisser <olga@...isser.org>
> > + * Author: Henrik Steen <henrist@...rist.net>
> > + * Author: Olivier Tilmans <olivier.tilmans@...ia-bell-labs.com>
> > + *
> > + * DualPI Improved with a Square (dualpi2)
> > + * Supports controlling scalable congestion controls (DCTCP, etc...)
> > + * Supports DualQ with PI2
> > + * Supports L4S ECN identifier
> > + *
> > + * References:
> > + * IETF draft submission:
> > + *   http://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08
> > + * ACM CoNEXT’16, Conference on emerging Networking EXperiments
> > + * and Technologies :
> > + * "PI2: PI Improved with a Square to support Scalable Congestion Controllers"
> > + * IETF draft submission:
> > + *   http://tools.ietf.org/html/draft-pan-aqm-pie-00
> > + * IEEE  Conference on High Performance Switching and Routing 2013 :
> > + * "PIE: A * Lightweight Control Scheme to Address the Bufferbloat Problem"
> > + * Partially based on the PIE implementation:
> > + * Copyright (C) 2013 Cisco Systems, Inc, 2013.
> > + * Author: Vijay Subramanian <vijaynsu@...co.com>
> > + * Author: Mythili Prabhu <mysuryan@...co.com>
> > + * ECN support is added by Naeem Khademi <naeemk@....uio.no>
> > + * University of Oslo, Norway.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/errno.h>
> > +#include <linux/skbuff.h>
> > +#include <linux/version.h>
> > +#include <net/pkt_sched.h>
> > +#include <net/inet_ecn.h>
> > +#include <net/dsfield.h>
> > +
> > +#define QUEUE_THRESHOLD 10000
> > +#define MAX_PROB  0xffffffff

The code in regular Pi just updated to UINT64_MAX for max probability.
Shouldn't this API use the same convention?