Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Gerhard Engleder <gerhard@engleder-embedded.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
Thread-Topic: [PATCH net-next 10/13] tsnep: deny tc-taprio changes to per-tc
 max SDU
Thread-Index: AQHYyE9kpcxLYCJ3dk68mHHPDBjrxq3g2nSAgAE9jQA=
Date:   Fri, 16 Sep 2022 13:57:53 +0000
Message-ID: <20220916135752.abmpagmyjt4gnolk@skbuf>
References: <20220914153303.1792444-1-vladimir.oltean@nxp.com>
 <20220914153303.1792444-11-vladimir.oltean@nxp.com>
 <ecf497e3-8934-1046-818e-4ee5dc5889eb@engleder-embedded.com>
In-Reply-To: <ecf497e3-8934-1046-818e-4ee5dc5889eb@engleder-embedded.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WNyZ292iFjO5imWRqrC2dUY+C005ZzXbZw5nb1Ib81BMSZX0N1VWxXNvLpHv?=
 =?us-ascii?Q?JedMW4D+5dcrDxxW4SI/jEL9QOFe8XPMriJFLX1tkHfvuCkMXxfC+BABQYKL?=
 =?us-ascii?Q?g/PV+EelBQp3fXanQGoIe2WNY2CTSsItJmOAX/M1ZbRPM78yiZ9Jy+Y5zd+Q?=
 =?us-ascii?Q?/ViqfJlv4+OBSMcR+YpFdNPxmXZnGV3HpZu/wMtJR+7PrK13b/h+ftthwNZ+?=
 =?us-ascii?Q?2oS/910452MsL0nEXgTqqLFZr0WYGhdN9ENzQbvSJV+ZwrzTmPk21fCpTidU?=
 =?us-ascii?Q?94+V0nF+o0ZATQxIneVdgjHNXhnC13wyv2hN9y81OmrcV6QJlGkLZDAnco4h?=
 =?us-ascii?Q?1eRNiaX0XeEWBMqjMt+sDiZQoH0upGttpRl+rFIM+i+Lrdx9OWppiqDrcfMy?=
 =?us-ascii?Q?Yf9fCilJIYRQUwZ+fG8CikDI2qIeD/3+QSQhrg0f0Exsc1FhkMK3HSAeSNFn?=
 =?us-ascii?Q?x3MY+JPwMTfIOeHndkyNiWu3N709ybttrsKJKflUW05xWiISypGMzJSKPieD?=
 =?us-ascii?Q?eaXWMyNnWmQDFOhKZ4FDHEKcQmf09o0b2krQDOkwnPy2D509KPMG+aX9jCrZ?=
 =?us-ascii?Q?zMaelk+rokJMonDyT7sTB4eaksEvr/cYSnTnlG47IC4OCViK+W2V9TiEPUK5?=
 =?us-ascii?Q?lzf/+3FWF98Cb/JX9uO29WJUCB3HYWLQ0mihQ0ugDCT3cX9EILYJdxYxnnCM?=
 =?us-ascii?Q?tSh/UghBWtLeiMz90jv6ZZnCBLEAYwMK+4+itrxkCMrhN4Jukz/kF2/RSmAO?=
 =?us-ascii?Q?YFWdsR2HEqwl2deMlot6xMqHCvPG87WAiO8FwEvNgE8Dk9PvUdeotA1ytNIN?=
 =?us-ascii?Q?hYJhWlo4ZTBddeNMXG/120X6WXs0RjY5fhnruBZCBGPI3nH7dZtOcYRI5+Yb?=
 =?us-ascii?Q?dU0JSEvqqUggWB0kAWSI+49oFvN6QfL4bnEBsEEeZs8Spq7ZGDeSPg83qA7k?=
 =?us-ascii?Q?QZD+uWF8UiW80LD757QBXHGrlPGzZHg7pLY0aNiF2Q6dB4P9tFnYioFTCfVb?=
 =?us-ascii?Q?JaMvpp09bt+bkKUyS2td9wBoJNZnblbnOaf9OSQ2KjsPoda+dduPDqguH+WO?=
 =?us-ascii?Q?WdWenpWMBwRfQlUJrqvcyrh0BokBur+cxg7Wmd1P/eqD1N7/GuiXnhxWUW91?=
 =?us-ascii?Q?ZsFeoY6MiqEVP09IQHZ0HEXHQ5kPzVZz1oz/VXQd2fRfpw8JvoN68Jh2/0og?=
 =?us-ascii?Q?3keF5FdxMKLCUnjDu0+4ll6Xi+anQIWSVmG0zDZqKT9YVYZ68mrCcU5SAgqz?=
 =?us-ascii?Q?AN2Ie/CfJMtvamd+ZfFrrw7ekg/VsI7SoseciO/AVMFTiaWLIwhFLD9+6xrg?=
 =?us-ascii?Q?xWay7HZ7jZYHZ9xR49VF0Jqjx+UJwA8u/jXmeTMLNa6lXFThLOchkrIvTy5P?=
 =?us-ascii?Q?45Pe4O/DpPdTc5hZkDOkzkBLcDDSyFeCDPPYid6NXUwwWyFet7bmPjroHNt+?=
 =?us-ascii?Q?EDle8pxlNswdJlORrKOrCByfO3EGUbZ+vHVQ3U+46fZajtsDLEFkLQfO9y7p?=
 =?us-ascii?Q?5NiPubWHt4fOKGgipQIFTZ4FJS3A1M412dm9SCMPO11j+szKxpC4WH5NWU1P?=
 =?us-ascii?Q?6g7ZyCxi7faTyRIoOQehGGpk+pCNrUBSvsg/QuBDErATN+U+OeM5kpumgvm6?=
 =?us-ascii?Q?TQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <886C1A575B7E6E4284D9BE0EFB332782@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 182933e4-55ec-4916-0676-08da97eb7381
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2022 13:57:53.6822
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ipQUN9kslDLLEDU72/UUUlaffXVt9kNcDd3w9t9dO+NP0t5Mevt5Lm+FKf+8X5XIuTWoc/s0FTCg2KiCHTDn1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR04MB7449
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.=