Messages in this thread | | | Date | Thu, 16 Feb 2023 12:35:36 +0200 | From | Vladimir Oltean <> | Subject | Re: [PATCH net-next 3/3] net/sched: taprio: dynamic max_sdu larger than the max_mtu is unlimited |
| |
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.
| |