Re: [PATCH net-next 3/3] net/sched: taprio: dynamic max_sdu larger than the max_mtu is unlimited

[Vladimir Oltean <vladimir.oltean@nxp.com>]

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.