[v4,net-next,0/9] Add tc-mqprio and tc-taprio support for preemptible traffic classes

Message

Vladimir Oltean April 3, 2023, 10:34 a.m. UTC

The last RFC in August 2022 contained a proposal for the UAPI of both
TSN standards which together form Frame Preemption (802.1Q and 802.3):
https://lore.kernel.org/netdev/[e-mail]/

It wasn't clear at the time whether the 802.1Q portion of Frame Preemption
should be exposed via the tc qdisc (mqprio, taprio) or via some other
layer (perhaps also ethtool like the 802.3 portion, or dcbnl), even
though the options were discussed extensively, with pros and cons:
https://lore.kernel.org/netdev/[e-mail]/

So the 802.3 portion got submitted separately and finally was accepted:
https://lore.kernel.org/netdev/[e-mail]/

leaving the only remaining question: how do we expose the 802.1Q bits?

This series proposes that we use the Qdisc layer, through separate
(albeit very similar) UAPI in mqprio and taprio, and that both these
Qdiscs pass the information down to the offloading device driver through
the common mqprio offload structure (which taprio also passes).

An implementation is provided for the NXP LS1028A on-board Ethernet
endpoint (enetc). Previous versions also contained support for its
embedded switch (felix), but this needs more work and will be submitted
separately.

Changes in v4:
- removed felix driver support

Changes in v3:
- fixed build error caused by "default" switch case with no code
- reordered patches: bug fix first, driver changes all at the end
- changed links from patchwork to lore
- passed extack down to ndo_setup_tc() for mqprio and taprio, and made
  use of it in ocelot

v2 at:
https://lore.kernel.org/netdev/[e-mail]/

Changes in v2:
- add missing EXPORT_SYMBOL_GPL(ethtool_dev_mm_supported)
- slightly reword some commit messages
- move #include <linux/ethtool_netlink.h> to the respective patch in
  mqprio
- remove self-evident comment "only for dump and offloading" in mqprio

v1 at:
https://lore.kernel.org/netdev/[e-mail]/

Vladimir Oltean (9):
  net: ethtool: create and export ethtool_dev_mm_supported()
  net/sched: mqprio: simplify handling of nlattr portion of TCA_OPTIONS
  net/sched: mqprio: add extack to mqprio_parse_nlattr()
  net/sched: mqprio: add an extack message to mqprio_parse_opt()
  net/sched: pass netlink extack to mqprio and taprio offload
  net/sched: mqprio: allow per-TC user input of FP adminStatus
  net/sched: taprio: allow per-TC user input of FP adminStatus
  net: enetc: rename "mqprio" to "qopt"
  net: enetc: add support for preemptible traffic classes

 drivers/net/ethernet/freescale/enetc/enetc.c  |  31 ++-
 drivers/net/ethernet/freescale/enetc/enetc.h  |   1 +
 .../net/ethernet/freescale/enetc/enetc_hw.h   |   4 +
 include/linux/ethtool_netlink.h               |   6 +
 include/net/pkt_sched.h                       |   3 +
 include/uapi/linux/pkt_sched.h                |  17 ++
 net/ethtool/mm.c                              |  23 +++
 net/sched/sch_mqprio.c                        | 187 +++++++++++++++---
 net/sched/sch_mqprio_lib.c                    |  14 ++
 net/sched/sch_mqprio_lib.h                    |   2 +
 net/sched/sch_taprio.c                        |  77 ++++++--
 11 files changed, 323 insertions(+), 42 deletions(-)

Comments

Vladimir Oltean April 3, 2023, 10:54 a.m. UTC | #1

On Mon, Apr 03, 2023 at 01:34:31PM +0300, Vladimir Oltean wrote:
> This series proposes that we use the Qdisc layer, through separate
> (albeit very similar) UAPI in mqprio and taprio, and that both these
> Qdiscs pass the information down to the offloading device driver through
> the common mqprio offload structure (which taprio also passes).

For those interested, the iproute2 companion patch set is available here:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/

Vladimir Oltean April 3, 2023, 11:04 a.m. UTC | #2

On Mon, Apr 03, 2023 at 01:34:31PM +0300, Vladimir Oltean wrote:
> This series proposes that we use the Qdisc layer, through separate
> (albeit very similar) UAPI in mqprio and taprio, and that both these
> Qdiscs pass the information down to the offloading device driver through
> the common mqprio offload structure (which taprio also passes).
> 
> An implementation is provided for the NXP LS1028A on-board Ethernet
> endpoint (enetc). Previous versions also contained support for its
> embedded switch (felix), but this needs more work and will be submitted
> separately.

+Claudiu. Sorry, it wasn't intentional. I removed the DSA maintainers
and the Felix driver maintainers, forgetting that Claudiu is a maintainer
for both Felix and ENETC, and thus, his refcount should stay 1 :)

On another note, this patch set just got superseded in patchwork:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
after I submitted an iproute2 patch set with the same name:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/

I think there's a namespacing problem in patchwork's series detection
algorithm ("net-next" is not "iproute2-next", and so, it is valid to
have both in flight) but I don't know where to look to fix that.
Jakub, could you perhaps help, please?

Jakub Kicinski April 3, 2023, 9:32 p.m. UTC | #3

On Mon, 3 Apr 2023 14:04:58 +0300 Vladimir Oltean wrote:
> On another note, this patch set just got superseded in patchwork:
> https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> after I submitted an iproute2 patch set with the same name:
> https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> 
> I think there's a namespacing problem in patchwork's series detection
> algorithm ("net-next" is not "iproute2-next", and so, it is valid to
> have both in flight) but I don't know where to look to fix that.
> Jakub, could you perhaps help, please?

I revived the series. I'm a bit weary about asking Konstantin to make
the pw-bot compare tree tags because people change trees all the time
(especially no tree -> net-next / net) and he would have to filter out
the version.. It's gonna get wobbly. Let's see if the problem gets more
common.

Vladimir Oltean April 3, 2023, 11:43 p.m. UTC | #4

On Mon, Apr 03, 2023 at 02:32:29PM -0700, Jakub Kicinski wrote:
> On Mon, 3 Apr 2023 14:04:58 +0300 Vladimir Oltean wrote:
> > On another note, this patch set just got superseded in patchwork:
> > https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> > after I submitted an iproute2 patch set with the same name:
> > https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> > 
> > I think there's a namespacing problem in patchwork's series detection
> > algorithm ("net-next" is not "iproute2-next", and so, it is valid to
> > have both in flight) but I don't know where to look to fix that.
> > Jakub, could you perhaps help, please?
> 
> I revived the series. I'm a bit weary about asking Konstantin to make
> the pw-bot compare tree tags because people change trees all the time
> (especially no tree -> net-next / net) and he would have to filter out
> the version.. It's gonna get wobbly. Let's see if the problem gets more
> common.

Thanks. Was it supposed to change state? Because it's still "superseded".

Let's wait for a few more days before merging, anyway, just in case there
are any other comments from the more TSN-oriented folks. I'm still not
completely happy with the UAPI duplication in 2 qdiscs, and no indication
that the duplication would stop at 2. For example, if I understand tc-etf
correctly, it would be possible to see bands as traffic classes, and so,
talk about preemptible bands and end up adding UAPI for those too.

Jakub Kicinski April 4, 2023, 12:11 a.m. UTC | #5

On Tue, 4 Apr 2023 02:43:39 +0300 Vladimir Oltean wrote:
> > I revived the series. I'm a bit weary about asking Konstantin to make
> > the pw-bot compare tree tags because people change trees all the time
> > (especially no tree -> net-next / net) and he would have to filter out
> > the version.. It's gonna get wobbly. Let's see if the problem gets more
> > common.  
> 
> Thanks. Was it supposed to change state? Because it's still "superseded".

Argh, the bot keeps rescanning and re-marking it as Superseded :(

We have a backup patch tracking method of ... what's unread in 
my inbox. So we should be able to rely on that.