diff mbox series

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

Message ID 20230215224632.2532685-4-vladimir.oltean@nxp.com
State New
Headers
Series taprio queueMaxSDU fixes |

Commit Message

Vladimir Oltean Feb. 15, 2023, 10:46 p.m. UTC 
  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>
---
 net/sched/sch_taprio.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Kurt Kanzenbach Feb. 16, 2023, 9:28 a.m. UTC | #1 
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?
Vladimir Oltean Feb. 16, 2023, 10:29 a.m. UTC | #2 
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.
Kurt Kanzenbach Feb. 16, 2023, 10:34 a.m. UTC | #3 
On Thu Feb 16 2023, 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.

Yes, exactly. It's visible by the user.

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

Yup. It doesn't really matter that much.

Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
Vladimir Oltean Feb. 16, 2023, 10:35 a.m. UTC | #4 
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.
diff mbox series

Patch

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 53ba4d6b0218..1f469861eae3 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -288,6 +288,8 @@  static void taprio_update_queue_max_sdu(struct taprio_sched *q,
 						    dev->hard_header_len + 1);
 			}
 			max_sdu_dynamic = max_frm_len - dev->hard_header_len;
+			if (max_sdu_dynamic > dev->max_mtu)
+				max_sdu_dynamic = U32_MAX;
 		}
 
 		max_sdu = min(max_sdu_dynamic, max_sdu_from_user);