RE: [EXT] Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of traffic classes

From: Jose Abreu <Jose.Abreu@synopsys.com>
To: Andre Guedes <andre.guedes@linux.intel.com>,
	Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: Po Liu <po.liu@nxp.com>,
	"alexandru.ardelean@analog.com" <alexandru.ardelean@analog.com>,
	"allison@lohutok.net" <allison@lohutok.net>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"ayal@mellanox.com" <ayal@mellanox.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"hauke.mehrtens@intel.com" <hauke.mehrtens@intel.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"pablo@netfilter.org" <pablo@netfilter.org>,
	"saeedm@mellanox.com" <saeedm@mellanox.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	"simon.horman@netronome.com" <simon.horman@netronome.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandru Marginean <alexandru.marginean@nxp.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Roy Zang <roy.zang@nxp.com>, Mingkai Hu <mingkai.hu@nxp.com>,
	Jerry Huang <jerry.huang@nxp.com>, Leo Li <leoyang.li@nxp.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>
Subject: RE: [EXT] Re: [v1,net-next, 1/2] ethtool: add setting frame preemption of traffic classes
Date: Thu, 9 Jan 2020 08:59:24 +0000	[thread overview]
Message-ID: <BN8PR12MB32663AE71CBF7CF0258C86D7D3390@BN8PR12MB3266.namprd12.prod.outlook.com> (raw)
In-Reply-To: <157853205713.36295.17877768211004089754@aguedesl-mac01.jf.intel.com>

From: Andre Guedes <andre.guedes@linux.intel.com>
Date: Jan/09/2020, 01:07:37 (UTC+00:00)

> After reading all this great discussion and revisiting the 802.1Q and 802.3br
> specs, I'm now leaning towards to not coupling Frame Preemption support under
> taprio qdisc. Besides what have been discussed, Annex S.2 from 802.1Q-2018
> foresees FP without EST so it makes me feel like we should keep them separate.

I agree that EST and FP can be used individually. But how can you 
specify the hold and release commands for gates without changing taprio qdisc user space API ?

> Regarding the FP configuration knobs, the following seems reasonable to me:
>     * Enable/disable FP feature
>     * Preemptable queue mapping
>     * Fragment size multiplier
> 
> I'm not sure about the knob 'timers (hold/release)' described in the quotes
> above. I couldn't find a match in the specs. If it refers to 'holdAdvance' and
> 'releaseAdvance' parameters described in 802.1Q-2018, I believe they are not
> configurable. Do we know any hardware where they are configurable?

Synopsys' HW supports reconfiguring these parameters. They are, however, 
fixed independently of Queues. i.e. all queues will have same holdAdvance / releaseAdvance.

---
Thanks,
Jose Miguel Abreu