Files
linux/include/uapi/linux
Vladimir Oltean a721c3e54b net/sched: taprio: allow per-TC user input of FP adminStatus
This is a duplication of the FP adminStatus logic introduced for
tc-mqprio. Offloading is done through the tc_mqprio_qopt_offload
structure embedded within tc_taprio_qopt_offload. So practically, if a
device driver is written to treat the mqprio portion of taprio just like
standalone mqprio, it gets unified handling of frame preemption.

I would have reused more code with taprio, but this is mostly netlink
attribute parsing, which is hard to transform into generic code without
having something that stinks as a result. We have the same variables
with the same semantics, just different nlattr type values
(TCA_MQPRIO_TC_ENTRY=5 vs TCA_TAPRIO_ATTR_TC_ENTRY=12;
TCA_MQPRIO_TC_ENTRY_FP=2 vs TCA_TAPRIO_TC_ENTRY_FP=3, etc) and
consequently, different policies for the nest.

Every time nla_parse_nested() is called, an on-stack table "tb" of
nlattr pointers is allocated statically, up to the maximum understood
nlattr type. That array size is hardcoded as a constant, but when
transforming this into a common parsing function, it would become either
a VLA (which the Linux kernel rightfully doesn't like) or a call to the
allocator.

Having FP adminStatus in tc-taprio can be seen as addressing the 802.1Q
Annex S.3 "Scheduling and preemption used in combination, no HOLD/RELEASE"
and S.4 "Scheduling and preemption used in combination with HOLD/RELEASE"
use cases. HOLD and RELEASE events are emitted towards the underlying
MAC Merge layer when the schedule hits a Set-And-Hold-MAC or a
Set-And-Release-MAC gate operation. So within the tc-taprio UAPI space,
one can distinguish between the 2 use cases by choosing whether to use
the TC_TAPRIO_CMD_SET_AND_HOLD and TC_TAPRIO_CMD_SET_AND_RELEASE gate
operations within the schedule, or just TC_TAPRIO_CMD_SET_GATES.

A small part of the change is dedicated to refactoring the max_sdu
nlattr parsing to put all logic under the "if" that tests for presence
of that nlattr.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ferenc Fejes <fejes@inf.elte.hu>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-13 22:22:10 -07:00
..
2022-09-15 09:08:09 +02:00
2022-04-19 13:13:47 +01:00
2021-11-01 13:36:08 +00:00
2022-08-11 10:31:19 -07:00
2022-06-07 10:20:42 -07:00
2021-11-26 16:48:59 +01:00
2023-02-10 17:54:45 -08:00
2023-01-20 09:33:22 +00:00
2022-08-23 14:54:54 -05:00
2022-04-04 08:55:23 +02:00
2023-01-18 17:12:37 -08:00
2023-03-16 21:20:32 -07:00
2021-10-07 13:51:11 +02:00
2022-08-10 13:49:50 +01:00
2023-02-16 13:50:50 +01:00
2022-03-11 08:28:05 -08:00
2021-11-15 07:53:10 -08:00
2022-06-03 20:09:27 +08:00
2022-09-20 09:13:38 +02:00
2022-10-19 09:01:44 +02:00
2022-12-01 20:06:06 -08:00
2023-03-16 21:20:32 -07:00
2022-09-07 16:46:03 +02:00
2021-07-06 10:37:46 -05:00
2022-09-20 09:13:38 +02:00
2023-01-04 14:44:13 -07:00
2023-01-26 10:52:18 +01:00
2022-11-17 11:04:23 -08:00
2022-09-27 17:29:09 -07:00
2023-02-20 19:26:56 -05:00
2022-12-05 10:30:47 +01:00