Re: [PATCH net-next 10/13] tsnep: deny tc-taprio changes to per-tc max SDU

From: Gerhard Engleder <gerhard@engleder-embedded.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
	Rui Sousa <rui.sousa@nxp.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Michael Walle <michael@walle.cc>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	Maxim Kochetkov <fido_max@inbox.ru>,
	Colin Foster <colin.foster@in-advantage.com>,
	Richie Pearn <richard.pearn@nxp.com>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	Vladimir Oltean <olteanv@gmail.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 10/13] tsnep: deny tc-taprio changes to per-tc max SDU
Date: Fri, 16 Sep 2022 21:53:56 +0200	[thread overview]
Message-ID: <7f09367e-2236-692c-4adf-cb262ff1c109@engleder-embedded.com> (raw)
In-Reply-To: <20220916135752.abmpagmyjt4gnolk@skbuf>

On 16.09.22 15:57, Vladimir Oltean wrote:
> On Thu, Sep 15, 2022 at 09:01:19PM +0200, Gerhard Engleder wrote:
>> Does it make any difference if the MAC already guarantees that too
>> long frames, which would violate the next taprio interval, will not
>> be transmitted?
> 
> This is not, in essence, about gate overruns, but about transmitting
> packets larger than X bytes for a traffic class. It also becomes about
> overruns and guard bands to avoid them, only in relation to certain
> hardware implementations.
> 
> But it could also be useful for reducing latency in a given time slot
> with mixed traffic classes where you don't have frame preemption.
> 
>> MACs are able to do that, switches not.
> 
> Switches could in principle be able to do that too, but just in store
> and forward mode (not cut-through).
> 
>> The user could be informed, that the MAC is considering the length of the
>> frames by accepting any max_sdu value lower than the MTU of the netdev.
> 
> By accepting any max_sdu lower than the MTU of the netdev, I would
> expect that the observable behavior is that the netdev will not send any
> frame for this traffic class that is larger than max_sdu. But if you
> accept the config as valid and not act on it, this will not be enforced
> by anyone. This is because of the way in which the taprio qdisc works in
> full offload mode.

Ok, denying max_sdu makes sense. It can be used to prevent too large
frames for a traffic class by discarding them.

In my opinion for MACs a software implementation would make sense even
in full offload mode, because it would prevent copying frames from RAM
to MAC which are discarded anyway. But that should be decided driver
specific.

Thanks for your explanations!