Re: [PATCH v2 net-next] selftests: forwarding: add Per-Stream Filtering and Policing test for Ocelot

From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Ferenc Fejes <fejes@inf.elte.hu>
Cc: peti.antal99@gmail.com, "andrew@lunn.ch" <andrew@lunn.ch>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	"vivien.didelot@gmail.com" <vivien.didelot@gmail.com>,
	"vinicius.gomes@intel.com" <vinicius.gomes@intel.com>,
	"shuah@kernel.org" <shuah@kernel.org>,
	"bigeasy@linutronix.de" <bigeasy@linutronix.de>,
	"davem@davemloft.net" <davem@davemloft.net>,
	Yannick Vignon <yannick.vignon@nxp.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	"idosch@nvidia.com" <idosch@nvidia.com>,
	"gerhard@engleder-embedded.com" <gerhard@engleder-embedded.com>,
	"Y.B. Lu" <yangbo.lu@nxp.com>,
	"jiri@nvidia.com" <jiri@nvidia.com>,
	"alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"kurt@linutronix.de" <kurt@linutronix.de>,
	Rui Sousa <rui.sousa@nxp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>
Subject: Re: [PATCH v2 net-next] selftests: forwarding: add Per-Stream Filtering and Policing test for Ocelot
Date: Fri, 17 Feb 2023 15:07:39 +0200	[thread overview]
Message-ID: <20230217130739.flqby6ok3wh5mklw@skbuf> (raw)
In-Reply-To: <1284d04958725d772750d6e3908301c8f8a379c1.camel@inf.elte.hu>

Hi Ferenc,

On Fri, Feb 17, 2023 at 09:03:30AM +0100, Ferenc Fejes wrote:
> I agree, it takes time to guess what the intention behind the wording
> of the standard in some cases. I have the standard in front of me right
> now and its 2163 pages... Even if I grep to IPV, the context is
> overwhelmingly dense.
> 
(...)
> I'll try to ask around too, thanks for pointing this out. My best
> understanding from the IPV that the standard treat it as skb->priority.
> It defines IPV as a 32bit signed value, which clearly imply similar
> semantics as skb->priority, which can be much larger than the number of
> the queues or traffic classes.

What would you say if we made the software act_gate implementation
simply alter skb->priority, which would potentially affect more stuff
including the egress-qos-map of a VLAN device in the output path of the
skb? It would definitely put less pressure on the networking data
structures, at the price of leaving an exceedingly unlikely case
uncovered.

> Oh, alright. I continue to think about alternatives over introducing
> new members into sk_buff. It would be very nice to have proper act_gate
> IPV handling without hardware offload. Its great to see the support of
> frame preemption and PSFP support in more and more hardware but on the
> other hand it makes the lack of the proper software mode operation more
> and more awkward.

I'm not sure that cyclic queuing and forwarding done with software
forwarding is going to be that practical anyway?