Date:   Thu, 16 Feb 2023 12:35:36 +0200
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Kurt Kanzenbach <kurt@linutronix.de>
Cc:     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>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Gerhard Engleder <gerhard@engleder-embedded.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 3/3] net/sched: taprio: dynamic max_sdu larger
 than the max_mtu is unlimited
Message-ID: <20230216103536.abju64jbpucfyqir@skbuf>
References: <20230215224632.2532685-1-vladimir.oltean@nxp.com>
 <20230215224632.2532685-4-vladimir.oltean@nxp.com>
 <87cz6aot67.fsf@kurt>
 <20230216102914.wat37qsih5xx3wk4@skbuf>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230216102914.wat37qsih5xx3wk4@skbuf>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?zyVDrr0n733ZHaDhuNQkeG60ldW14qgs8pjQJWXAf2tpuoLPAulKBcEHv8Oc?=
 =?us-ascii?Q?JEJROOJckxi/JqAf3+Jwh5w61gfaI0F/QYF8mzC8dRrOEo2XF0xLGDIqKQAv?=
 =?us-ascii?Q?VVYPoPa/W0hev/VoQgDAgG6KCNmnazFT4gaQ7HHv7AKnDLLvw20vOiOynBAZ?=
 =?us-ascii?Q?AyRbk32C/V/rwFS9vuY4v1ymF0/mMHYEE94sTUoGBqjcIJUY6fw9xebI70oV?=
 =?us-ascii?Q?3vRB1imK5jnIpQhrUMhJkMqTs9kc0/p4+k9wx0JSBc+B4MFZornMhPMGR1pc?=
 =?us-ascii?Q?FpMxgK2Id9SGbUt+/4Bg3KngOxpN8N0fGXj23gJUXCmaPL/M/jKcMX76dusB?=
 =?us-ascii?Q?Z34j2O0w0hQv+VBlc+rGvpCiWQnlCKIgehxn0RUFcn51YOtkbeIKQAJeivVH?=
 =?us-ascii?Q?2PeWG+viw7IXPr52YTLF5Yft397JtHdRpuyIqjVjxVAKdbYQJ/6HOLHaMtOQ?=
 =?us-ascii?Q?PxUhqu5p+fV16sn4pEb9tv676MNRV/JLID82Vu4atyKxvQlq2W8nUg3YP7qt?=
 =?us-ascii?Q?CuToxWwRknSdrL3U1Cb9WMw4965pXptX9VoOQJD1MeDRmN3n4txpvuAoFJmq?=
 =?us-ascii?Q?rSg9gZP0LX2/ZB6EzhZwt9msIlsrcR3ad6mjGV1y+Y8ZvvQzvnYkKAY6oWVW?=
 =?us-ascii?Q?6STmflev34yuCF7AT0BAOFlm0HyNgfShl3rG7Eraezc4jqyb/8k/CkFsCuWe?=
 =?us-ascii?Q?l6Mg4iWIgHO5jctnSdas9V3zQwrwqOVuqQzkcvfVNxLvAV/QhPzLJxAKFlJw?=
 =?us-ascii?Q?xx3GpebwNri02+uzZaVFCMy+dy8we6gcZZ5JuUNQU3vbXS8fIZ/xwwbzgJ/o?=
 =?us-ascii?Q?vDzJ2CG88mwoV+Q+JB2IWG4PHYxuMlP2WO0zeQNfk/7OKW2zNw7rQoaKHrbV?=
 =?us-ascii?Q?H3rgTozJ9Bg3D68i1njH0lVYHS9zD9EFThz0k/5Cha6SxZUiSI4rXwrYxOy7?=
 =?us-ascii?Q?DVZzLX+b/h4+L9z18bi0QkKIseM9at/wRyJBuHXyJSn/1Q8amID4EzxwQA1i?=
 =?us-ascii?Q?QcFkMzDkvK3xBngHoBBb151cys5zLDpJVg7zuKWg4Pk7skghhXwjlFl1YnQE?=
 =?us-ascii?Q?hqYaGC2YshUGzK2p5bywna89VONQxFj84UKjQ434O2RW63jf06zesiBncYTP?=
 =?us-ascii?Q?O8CIW7gED5760ymRdLPmcFxr/cVtU1L3t0qaYjkLyJ5zGsHnGx68WcdFdjAA?=
 =?us-ascii?Q?QQAjKXpPYbBVGqcJ67nPx9IrD49trs1QguUhgvXKeEbu6R7taWfEN2c7ypIV?=
 =?us-ascii?Q?0bM5AuLPWjk14MKagE3Y8xlaOlS9UdF8jBk4Rk29Dv1nu9P4QRaDoCR7kXlK?=
 =?us-ascii?Q?Rm/EsWwnzA7UjM3+zcp/4aMYNfOA0IrQE256ZQcr91qFp5yQU0e3WN33CMwm?=
 =?us-ascii?Q?Zc8vAM+8++aN0wqwzMlmyahtOCGB/3IpWM2pCJkMJiNtRqe4N9As2mr3/9x0?=
 =?us-ascii?Q?If+s93UnYuJaMIMA91IL2OKONqj0p5sfTsT910yX3RqdCKPguYCpgz3WlUCc?=
 =?us-ascii?Q?jzta/bb2ZixVMfPGM16xmUkzcEtViGJW5nc0aT5atwBIIIOA5OKOeg+VjhPU?=
 =?us-ascii?Q?BITKGKRN1tyjhQA6BQyqPqqwa4VLOEQCQrQoOMJbYFMrkT6aNZqkFhffH+KA?=
 =?us-ascii?Q?QQ=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 430c287b-7158-4d17-d987-08db10098c9e
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2023 10:35:40.4433
 (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: /IGPOOg8KCLYuUqzxj43nzYjrw8BhkISmick+G/1lXgHlmGgHmGGqfK6KtrJROPCgqkLFX12gWtS1YKfDVWdaw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB9591
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 16, 2023 at 12:29:14PM +0200, Vladimir Oltean wrote:
> On Thu, Feb 16, 2023 at 10:28:48AM +0100, Kurt Kanzenbach wrote:
> > On Thu Feb 16 2023, Vladimir Oltean wrote:
> > > It makes no sense to keep randomly large max_sdu values, especially if
> > > larger than the device's max_mtu. These are visible in "tc qdisc show".
> > > Such a max_sdu is practically unlimited and will cause no packets for
> > > that traffic class to be dropped on enqueue.
> > >
> > > Just set max_sdu_dynamic to U32_MAX, which in the logic below causes
> > > taprio to save a max_frm_len of U32_MAX and a max_sdu presented to user
> > > space of 0 (unlimited).
> > >
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > 
> > Doesn't this deserve a Fixes tag as well?
> 
> No, I don't think so. It's just so that the user (and later, the offloading
> driver) doesn't see arbitrarily large values, just a simplifying 0. I guess
> it could potentially make a difference to the software taprio data path with
> TSO, if the max MTU is comparable with the segment sizes.
> 
> Anyway, with or without the Fixes tag, the patch lands in the same place.

I should probably clarify the term "later". Right now, taprio_enable_offload()
still passes q->max_sdu[tc] to the offloading driver and not sched->max_sdu[tc],
or in other words, it always passes what the user has requested, not the
value postprocessed by taprio to take the current speed into consideration.