[PATCH net-next 0/3] taprio queueMaxSDU fixes

[PATCH net-next 0/3] taprio queueMaxSDU fixes

[Vladimir Oltean]

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

[PATCH net-next 1/3] net/sched: taprio: fix calculation of maximum gate durations

[Vladimir Oltean]

taprio_calculate_gate_durations() depends on netdev_get_num_tc() and
this returns 0. So it calculates the maximum gate durations for no
traffic class.

I had tested the blamed commit only with another patch in my tree, one
which in the end I decided isn't valuable enough to submit ("net/sched:
taprio: mask off bits in gate mask that exceed number of TCs").

The problem is that having this patch threw off my testing. By moving
the netdev_set_num_tc() call earlier, we implicitly gave to
taprio_calculate_gate_durations() the information it needed.

Extract only the portion from the unsubmitted change which applies the
mqprio configuration to the netdev earlier.

Link: https://patchwork.kernel.org/project/netdevbpf/patch/20230130173145.475943-15-vladimir.oltean@nxp.com/
Fixes: a306a90c8ffe ("net/sched: taprio: calculate tc gate durations")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 net/sched/sch_taprio.c | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 9781b47962bb..556e72ec0f38 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -1833,23 +1833,6 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
 		goto free_sched;
 	}
 
-	err = parse_taprio_schedule(q, tb, new_admin, extack);
-	if (err < 0)
-		goto free_sched;
-
-	if (new_admin->num_entries == 0) {
-		NL_SET_ERR_MSG(extack, "There should be at least one entry in the schedule");
-		err = -EINVAL;
-		goto free_sched;
-	}
-
-	err = taprio_parse_clockid(sch, tb, extack);
-	if (err < 0)
-		goto free_sched;
-
-	taprio_set_picos_per_byte(dev, q);
-	taprio_update_queue_max_sdu(q, new_admin, stab);
-
 	if (mqprio) {
 		err = netdev_set_num_tc(dev, mqprio->num_tc);
 		if (err)
@@ -1867,6 +1850,23 @@ static int taprio_change(struct Qdisc *sch, struct nlattr *opt,
 					       mqprio->prio_tc_map[i]);
 	}
 
+	err = parse_taprio_schedule(q, tb, new_admin, extack);
+	if (err < 0)
+		goto free_sched;
+
+	if (new_admin->num_entries == 0) {
+		NL_SET_ERR_MSG(extack, "There should be at least one entry in the schedule");
+		err = -EINVAL;
+		goto free_sched;
+	}
+
+	err = taprio_parse_clockid(sch, tb, extack);
+	if (err < 0)
+		goto free_sched;
+
+	taprio_set_picos_per_byte(dev, q);
+	taprio_update_queue_max_sdu(q, new_admin, stab);
+
 	if (FULL_OFFLOAD_IS_ENABLED(q->flags))
 		err = taprio_enable_offload(dev, q, new_admin, extack);
 	else
-- 
2.34.1

[PATCH net-next 2/3] net/sched: taprio: don't allow dynamic max_sdu to go negative after stab adjustment

[Vladimir Oltean]

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 <vladimir.oltean@nxp.com>
---
 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

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

[Vladimir Oltean]

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(+)

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

Re: [PATCH net-next 1/3] net/sched: taprio: fix calculation of maximum gate durations

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On Thu Feb 16 2023, Vladimir Oltean wrote:
> taprio_calculate_gate_durations() depends on netdev_get_num_tc() and
> this returns 0. So it calculates the maximum gate durations for no
> traffic class.
>
> I had tested the blamed commit only with another patch in my tree, one
> which in the end I decided isn't valuable enough to submit ("net/sched:
> taprio: mask off bits in gate mask that exceed number of TCs").
>
> The problem is that having this patch threw off my testing. By moving
> the netdev_set_num_tc() call earlier, we implicitly gave to
> taprio_calculate_gate_durations() the information it needed.
>
> Extract only the portion from the unsubmitted change which applies the
> mqprio configuration to the netdev earlier.
>
> Link: https://patchwork.kernel.org/project/netdevbpf/patch/20230130173145.475943-15-vladimir.oltean@nxp.com/
> Fixes: a306a90c8ffe ("net/sched: taprio: calculate tc gate durations")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: [PATCH net-next 2/3] net/sched: taprio: don't allow dynamic max_sdu to go negative after stab adjustment

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

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 <vladimir.oltean@nxp.com>

Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

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

[Vladimir Oltean]

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.

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

[Kurt Kanzenbach]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

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

[Vladimir Oltean]

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.

Re: [PATCH net-next 0/3] taprio queueMaxSDU fixes

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (master)
by Paolo Abeni <pabeni@redhat.com>:

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