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: <DB5PR05MB1895F4C605BD38C7735BBADEAC590@DB5PR05MB1895.eurprd05.prod.outlook.com>
Date:   Mon, 30 Oct 2017 14:10:16 +0000
From:   Nogah Frankel <nogahf@...lanox.com>
To:     Roman Mashak <mrv@...atatu.com>, Jiri Pirko <jiri@...nulli.us>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        mlxsw <mlxsw@...lanox.com>, "andrew@...n.ch" <andrew@...n.ch>,
        "vivien.didelot@...oirfairelinux.com" 
        <vivien.didelot@...oirfairelinux.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "ganeshgr@...lsio.com" <ganeshgr@...lsio.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Matan Barak <matanb@...lanox.com>,
        "Leon Romanovsky" <leonro@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        "pieter.jansenvanvuuren@...ronome.com" 
        <pieter.jansenvanvuuren@...ronome.com>,
        "john.hurley@...ronome.com" <john.hurley@...ronome.com>,
        "alexander.h.duyck@...el.com" <alexander.h.duyck@...el.com>,
        Or Gerlitz <ogerlitz@...lanox.com>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>
Subject: RE: [patch net-next RFC 1/9] net_sch: red: Add offload ability to RED
 qdisc



> -----Original Message-----
> From: Roman Mashak [mailto:mrv@...atatu.com]
> Sent: Monday, October 30, 2017 2:47 PM
> To: Jiri Pirko <jiri@...nulli.us>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; Nogah Frankel <nogahf@...lanox.com>;
> jhs@...atatu.com; xiyou.wangcong@...il.com; mlxsw <mlxsw@...lanox.com>;
> andrew@...n.ch; vivien.didelot@...oirfairelinux.com; f.fainelli@...il.com;
> michael.chan@...adcom.com; ganeshgr@...lsio.com; Saeed Mahameed
> <saeedm@...lanox.com>; Matan Barak <matanb@...lanox.com>; Leon Romanovsky
> <leonro@...lanox.com>; Ido Schimmel <idosch@...lanox.com>;
> jakub.kicinski@...ronome.com; simon.horman@...ronome.com;
> pieter.jansenvanvuuren@...ronome.com; john.hurley@...ronome.com;
> alexander.h.duyck@...el.com; Or Gerlitz <ogerlitz@...lanox.com>;
> john.fastabend@...il.com
> Subject: Re: [patch net-next RFC 1/9] net_sch: red: Add offload ability to RED qdisc
> 
> Jiri Pirko <jiri@...nulli.us> writes:
> 
> 
> [...]
> 
> > +static void red_unoffload(struct Qdisc *sch)
> > +{
> > +	struct net_device *dev = qdisc_dev(sch);
> > +	struct tc_red_qopt_offload opt = {
> > +		.handle = sch->handle,
> > +		.command = TC_RED_DESTROY,
> > +		.parent = sch->parent,
> > +	};
> > +
> > +	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
> > +		return;
> > +
> > +	dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED,  &opt);
> > +}
> > +
> 
> > @@ -162,6 +179,28 @@ static const struct nla_policy red_policy[TCA_RED_MAX + 1] = {
> >  	[TCA_RED_MAX_P] = { .type = NLA_U32 },
> >  };
> >
> > +static int red_offload(struct Qdisc *sch)
> > +{
> > +	struct red_sched_data *q = qdisc_priv(sch);
> > +	struct net_device *dev = qdisc_dev(sch);
> > +	struct tc_red_qopt_offload opt = {
> > +		.handle = sch->handle,
> > +		.command = TC_RED_REPLACE,
> > +		.parent = sch->parent,
> > +		.set = {
> > +			.min = q->parms.qth_min >> q->parms.Wlog,
> > +			.max = q->parms.qth_max >> q->parms.Wlog,
> > +			.probability = q->parms.max_P,
> > +			.is_ecn = red_use_ecn(q),
> > +		},
> > +	};
> > +
> > +	if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
> > +		return -EOPNOTSUPP;
> > +
> > +	return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt);
> > +}
> > +
> 
> [...]
> 
> Can't red_unoffload() and red_offload() be unified in a single API? For
> example, red_offload(struct Qdisc *sch, bool enable) ?

I will unify them.
Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ