This fixes 3 issues noticed while attempting to reoffload the
dynamically calculated queueMaxSDU values. These are:
- Dynamic queueMaxSDU is not calculated correctly due to a lost patch
- Dynamically calculated queueMaxSDU needs to be clamped on the low end
- Dynamically calculated queueMaxSDU needs to be clamped on the high end
Vladimir Oltean (3):
net/sched: taprio: fix calculation of maximum gate durations
net/sched: taprio: don't allow dynamic max_sdu to go negative after
stab adjustment
net/sched: taprio: dynamic max_sdu larger than the max_mtu is
unlimited
net/sched/sch_taprio.c | 44 +++++++++++++++++++++++++-----------------
1 file changed, 26 insertions(+), 18 deletions(-)
--
2.34.1
The overhead specified in the size table comes from the user. With small
time intervals (or gates always closed), the overhead can be larger than
the max interval for that traffic class, and their difference is
negative.
What we want to happen is for max_sdu_dynamic to have the smallest
non-zero value possible (1) which means that all packets on that traffic
class are dropped on enqueue. However, since max_sdu_dynamic is u32, a
negative is represented as a large value and oversized dropping never
happens.
Use max_t with int to force a truncation of max_frm_len to no smaller
than dev->hard_header_len + 1, which in turn makes max_sdu_dynamic no
smaller than 1.
Fixes: fed87cc6718a ("net/sched: taprio: automatically calculate queueMaxSDU based on TC gate durations")
Signed-off-by: Vladimir Oltean <[email protected]>
---
net/sched/sch_taprio.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 556e72ec0f38..53ba4d6b0218 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -279,8 +279,14 @@ static void taprio_update_queue_max_sdu(struct taprio_sched *q,
u32 max_frm_len;
max_frm_len = duration_to_length(q, sched->max_open_gate_duration[tc]);
- if (stab)
+ /* Compensate for L1 overhead from size table,
+ * but don't let the frame size go negative
+ */
+ if (stab) {
max_frm_len -= stab->szopts.overhead;
+ max_frm_len = max_t(int, max_frm_len,
+ dev->hard_header_len + 1);
+ }
max_sdu_dynamic = max_frm_len - dev->hard_header_len;
}
--
2.34.1
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 <[email protected]>
---
net/sched/sch_taprio.c | 2 ++
1 file changed, 2 insertions(+)
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);
--
2.34.1
On Thu Feb 16 2023, Vladimir Oltean wrote:
> The overhead specified in the size table comes from the user. With small
> time intervals (or gates always closed), the overhead can be larger than
> the max interval for that traffic class, and their difference is
> negative.
>
> What we want to happen is for max_sdu_dynamic to have the smallest
> non-zero value possible (1) which means that all packets on that traffic
> class are dropped on enqueue. However, since max_sdu_dynamic is u32, a
> negative is represented as a large value and oversized dropping never
> happens.
>
> Use max_t with int to force a truncation of max_frm_len to no smaller
> than dev->hard_header_len + 1, which in turn makes max_sdu_dynamic no
> smaller than 1.
>
> Fixes: fed87cc6718a ("net/sched: taprio: automatically calculate queueMaxSDU based on TC gate durations")
> Signed-off-by: Vladimir Oltean <[email protected]>
Reviewed-by: Kurt Kanzenbach <[email protected]>
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 <[email protected]>
Doesn't this deserve a Fixes tag as well?
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 <[email protected]>
>
> 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.
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 <[email protected]>
> >
> > 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.
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 <[email protected]>
>>
>> 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 <[email protected]>
Hello:
This series was applied to netdev/net-next.git (master)
by Paolo Abeni <[email protected]>:
On Thu, 16 Feb 2023 00:46:29 +0200 you wrote:
> This fixes 3 issues noticed while attempting to reoffload the
> dynamically calculated queueMaxSDU values. These are:
> - Dynamic queueMaxSDU is not calculated correctly due to a lost patch
> - Dynamically calculated queueMaxSDU needs to be clamped on the low end
> - Dynamically calculated queueMaxSDU needs to be clamped on the high end
>
> Vladimir Oltean (3):
> net/sched: taprio: fix calculation of maximum gate durations
> net/sched: taprio: don't allow dynamic max_sdu to go negative after
> stab adjustment
> net/sched: taprio: dynamic max_sdu larger than the max_mtu is
> unlimited
>
> [...]
Here is the summary with links:
- [net-next,1/3] net/sched: taprio: fix calculation of maximum gate durations
https://git.kernel.org/netdev/net-next/c/09dbdf28f9f9
- [net-next,2/3] net/sched: taprio: don't allow dynamic max_sdu to go negative after stab adjustment
https://git.kernel.org/netdev/net-next/c/bdf366bd867c
- [net-next,3/3] net/sched: taprio: dynamic max_sdu larger than the max_mtu is unlimited
https://git.kernel.org/netdev/net-next/c/64cb6aad1232
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html