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: AQHYyE9kpcxLYCJ3dk68mHHPDBjrxq3g2nSAgAE9jQCAAGN8AIAAJ8OA
Date:   Fri, 16 Sep 2022 22:16:16 +0000
Message-ID: <20220916221615.k33pn7zdsixcz4mz@skbuf>
References: <20220914153303.1792444-1-vladimir.oltean@nxp.com>
 <20220914153303.1792444-11-vladimir.oltean@nxp.com>
 <ecf497e3-8934-1046-818e-4ee5dc5889eb@engleder-embedded.com>
 <20220916135752.abmpagmyjt4gnolk@skbuf>
 <7f09367e-2236-692c-4adf-cb262ff1c109@engleder-embedded.com>
In-Reply-To: <7f09367e-2236-692c-4adf-cb262ff1c109@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?FoK5lHWQsKV3VW2ai1ReTGN5M+nrOh/iUZxbAzYtIZik55cyql0KF+EBe/Op?=
 =?us-ascii?Q?mFaKMIdSqI3Ymw40FHO5RkRKeuA8XqvGtuyF3UmI0WIUe8RPzlREJQMPhseE?=
 =?us-ascii?Q?ukMlNOBp/AeBxDINit/JUne+cQhfR9cx6aX3xzDHuckllsEYPBSHnooOlByc?=
 =?us-ascii?Q?GBdRSZTpdLP9BWFOYOtNKNj+SvXdt3fzI5VzUUIbyubvzsnET4ooMXfAcfNS?=
 =?us-ascii?Q?FEhALgiNm6yLqkd6Pv9KHIHPYBPkgQ4MjzAO+ILlu+Wm++ojHsWr+wZjx4LQ?=
 =?us-ascii?Q?hYkKeI44gYBG86ig4bH5Py6XuDJUjYEBlxQG9yfCk2oZQGvPNiheaqUHYshJ?=
 =?us-ascii?Q?YcDvRRL+gh2VcsJq/+ONDIPWbnK3rMSb0QsOBKdNPh/N5Te+aPNQMnNaz/yO?=
 =?us-ascii?Q?bk21hw1I/lByvi7KYH3Nbo8rAup5eCK/6i4+r0cFOur1ldxQoOZnwrboz0ed?=
 =?us-ascii?Q?h1Ofh/QzxtGyZZtxxAwlpogcUJiIn7uaJWMNMb46cNUOUWE9aOos/XPWeKgs?=
 =?us-ascii?Q?wadkcKWz0h/xk5me39Ga982Mn7m1iEdtSBOdzG0d0k5TAfE0tYoUckV9TL9p?=
 =?us-ascii?Q?WQ0XI+CWMswaJzMWwVfCUG04h+7LwUDToUtufdSf3sGBBzpnFvTcXD8o4Dvc?=
 =?us-ascii?Q?5LwgyAWus4cIecZ3arC8WiPZD9+SoKymjtACm14EhV7+8kxJWtF+gGMCvvnX?=
 =?us-ascii?Q?bBS5PpubqcQLWCowKE9ZUMDCNKxupojt7lTEW1AOHwbyJXdXjFf23oz1HXPF?=
 =?us-ascii?Q?FonUg9WB3dZNQHFlnINFnx0sGmmgZnYzbKnbTALmvdhaCYxW5rlp+cVUt0Bz?=
 =?us-ascii?Q?Fza2kMJ9tDRqhMbvXTxcWk61XpTKLTc7K0H2j0toVlMnOA+U3P9QuxUmgvPs?=
 =?us-ascii?Q?yzrEdy0pcVxkSZz5NdzB7HtHVcgyQbuKI9INxdsvKQFgkxAES0EN+ZXGLQ6t?=
 =?us-ascii?Q?dsrze98EsvSkwAskTbGlVwsAsBDI8tXlOEg4HU6h59e+I16AhcwdvLyHr1ZP?=
 =?us-ascii?Q?L4D8VV4Ie5glimnPDFwy4TFB05dMtMt9a2viYALqWOGL8BQ6axWZ5scEFODa?=
 =?us-ascii?Q?CSQ50RnXDRR3h0tZeV/TKpmkWq7tBk5UpUjK65Ro1ubH6oc1SzB567nl6lLX?=
 =?us-ascii?Q?QAsQjluc/dmlWdotllp0ySIiUf5Lhl5F+OQWfCjw0HRwbBYKfaE6Fv9UeBvA?=
 =?us-ascii?Q?hyIvqZupvpQx1XzhNMY5696Qwag7PE2fIXbd/I5WFFFmiuUVWoBITzXMlvUN?=
 =?us-ascii?Q?cvzbvxD05cYm3Mo/sYF2u1ug71nZ3WSM0+JkgODlQUXIwP/dqcOnJ5+5QPTm?=
 =?us-ascii?Q?rveIZc8BoRs448KPI/t61R6w5Rh9ZxVLKz2kwk7lXj3b2GlO1+ZEbkGk9dtc?=
 =?us-ascii?Q?+BP1aeR7EGZuxUDpZ0Z0qdWr+Cpx95L0cVtY7Jj8IT8gF5lNFB9arRl2IpZz?=
 =?us-ascii?Q?PzIvew/EAw2myDIQcpa0wRRDE8Y5c8H8jUy6twHvCbygA26J9UYN9tAGIpol?=
 =?us-ascii?Q?i65WF9wglTn0ij52jayUheCXX3PobxJCk6JBqIcGO57ysHjaPJJCq6LuvbO9?=
 =?us-ascii?Q?zibKwkUq4TD8FLW/UUX59RUqIxMh7+AvGbLKm25G5lPYJn1S6ixzXUOyNgPM?=
 =?us-ascii?Q?yw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <098727EF00782F43AE38B5EBA76BE447@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: 53bb0052-2b5e-4afc-42f0-08da98311318
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2022 22:16:16.6898
 (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: N4ktNJi7RTROvG8ilp7hYVKJ1mSdMDhT25MaDthx63bbMcNxK5sGAD/18lvruZiB1UtjVLQ0jeQeFij7bcI/Hw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8624
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 Fri, Sep 16, 2022 at 09:53:56PM +0200, Gerhard Engleder wrote:
> Ok, denying max_sdu makes sense. It can be used to prevent too large
> frames for a traffic class by discarding them.
>=20
> 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.
>=20
> Thanks for your explanations!

Depending on how your hardware architecture looks like, discarding the
oversized frames in the driver might or might not be possible. If you
have for example queues exposed to user space, you're at user space's
mercy. Since for example enetc can have virtual station interfaces
(essentially a set of queues with a way to reach them, by MAC address)
exported using vfio-pci to a guest OS running arbitrary software,
dropping them in the physical port MAC is pretty much the only way you
can ensure you meet your latency target.=