From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH net-next 05/14] nfp: abm: add simple RED offload
Date: Mon, 28 May 2018 16:05:07 -0700
Message-ID: <20180528160507.4a2ff81a@cakuba>
References: <20180526045338.10993-1-jakub.kicinski@netronome.com>
        <20180526045338.10993-6-jakub.kicinski@netronome.com>
        <63246dc9-740d-ea72-e15e-599487b3a845@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: davem@davemloft.net, jiri@resnulli.us, xiyou.wangcong@gmail.com,
        john.fastabend@gmail.com, netdev@vger.kernel.org,
        oss-drivers@netronome.com, alexei.starovoitov@gmail.com,
        nogahf@mellanox.com, yuvalm@mellanox.com, gerlitz.or@gmail.com
To: Nogah Frankel <nogah.frankel@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f193.google.com ([209.85.216.193]:33456 "EHLO
        mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S934027AbeE1XFM (ORCPT
        <rfc822;netdev@vger.kernel.org>); Mon, 28 May 2018 19:05:12 -0400
Received: by mail-qt0-f193.google.com with SMTP id e8-v6so16540237qth.0
        for <netdev@vger.kernel.org>; Mon, 28 May 2018 16:05:12 -0700 (PDT)
In-Reply-To: <63246dc9-740d-ea72-e15e-599487b3a845@gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Hi Nogah!

On Mon, 28 May 2018 18:49:51 +0300, Nogah Frankel wrote:
> > +static int
> > +nfp_abm_red_replace(struct net_device *netdev, struct nfp_abm_link *alink,
> > +		    struct tc_red_qopt_offload *opt)
> > +{
> > +	struct nfp_port *port = nfp_port_from_netdev(netdev);
> > +	int err;
> > +
> > +	if (opt->set.min != opt->set.max || !opt->set.is_ecn) {  
> 
> I am a bit worried about the min == max.
> sch_red doesn't really support it. It will calculate incorrect delta 
> value. (And that only if tc_red_eval_P in iproute2 won't reject it).
> You might maybe use max = min+1,  because in real life it will probably 
> act the same but without this problem.

I remember having a long think about this when I wrote the code.  
My conclusion was that the two would operate almost the same, and
setting min == max may be most obvious to the user.

If min + 1 == max sch_red would act probabilistically for qavg == min,
which is not what the card would do.

Userspace now does this:

tc_red_eval_P() {
	int i = qmax - qmin;
 
	if (!i)
		return 0;
	if (i < 0)
		return -1;
	...
}

And you've fixed delta to be treated as 1 to avoid division by 0 in
commit 5c472203421a ("net_sched: red: Avoid devision by zero"):

red_set_parms() {
	int delta = qth_max - qth_min;
	u32 max_p_delta;

	p->qth_min	= qth_min << Wlog;
	p->qth_max	= qth_max << Wlog;
	p->Wlog		= Wlog;
	p->Plog		= Plog;
	if (delta <= 0)
		delta = 1;
	p->qth_delta	= delta;
	...
}

So we should be safe.  Targets will match.  Probability adjustment for
adaptive should work correctly.  Which doesn't matter anyway, since we
will never use the probabilistic action...

> Nogah Frankel
> (from a new mail address)

Noted :)