mbox series

[v3,net-next,00/13] Add tc-mqprio and tc-taprio support for preemptible traffic classes

Message ID 20230220122343.1156614-1-vladimir.oltean@nxp.com
Headers
Series Add tc-mqprio and tc-taprio support for preemptible traffic classes |

Message

Vladimir Oltean Feb. 20, 2023, 12:23 p.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/20220816222920.1952936-1-vladimir.oltean@nxp.com/

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

So the 802.3 portion got submitted separately and finally was accepted:
https://lore.kernel.org/netdev/20230119122705.73054-1-vladimir.oltean@nxp.com/

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

Implementations are provided for the NXP LS1028A on-board Ethernet
(enetc, felix).

Some patches should have maybe belonged to separate series, leaving here
only patches 07/13 - 13/13, for ease of review. That may be true,
however due to a perceived lack of time to wait for the prerequisite
cleanup to be merged, here they are all together.

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

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

Vladimir Oltean (13):
  net: ethtool: fix __ethtool_dev_mm_supported() implementation
  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: mscc: ocelot: add support for mqprio offload
  net: dsa: felix: act upon the mqprio qopt in taprio offload
  net: mscc: ocelot: add support for preemptible traffic classes
  net: enetc: add support for preemptible traffic classes

 drivers/net/dsa/ocelot/felix_vsc9959.c        |  44 ++++-
 drivers/net/ethernet/freescale/enetc/enetc.c  |  31 ++-
 drivers/net/ethernet/freescale/enetc/enetc.h  |   1 +
 .../net/ethernet/freescale/enetc/enetc_hw.h   |   4 +
 drivers/net/ethernet/mscc/ocelot.c            |  53 +++++
 drivers/net/ethernet/mscc/ocelot.h            |   2 +
 drivers/net/ethernet/mscc/ocelot_mm.c         |  52 +++++
 include/linux/ethtool_netlink.h               |   6 +
 include/net/pkt_sched.h                       |   3 +
 include/soc/mscc/ocelot.h                     |   6 +
 include/uapi/linux/pkt_sched.h                |  17 ++
 net/ethtool/mm.c                              |  25 ++-
 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 ++++++--
 16 files changed, 474 insertions(+), 50 deletions(-)

Comments

Jakub Kicinski Feb. 21, 2023, 12:55 a.m. UTC | #1 
On Mon, 20 Feb 2023 14:23:30 +0200 Vladimir Oltean wrote:
> Some patches should have maybe belonged to separate series, leaving here
> only patches 07/13 - 13/13, for ease of review. That may be true,
> however due to a perceived lack of time to wait for the prerequisite
> cleanup to be merged, here they are all together.

net-next is already closed, sorry :(
Vladimir Oltean Feb. 21, 2023, 1 a.m. UTC | #2 
On Mon, Feb 20, 2023 at 04:55:02PM -0800, Jakub Kicinski wrote:
> On Mon, 20 Feb 2023 14:23:30 +0200 Vladimir Oltean wrote:
> > Some patches should have maybe belonged to separate series, leaving here
> > only patches 07/13 - 13/13, for ease of review. That may be true,
> > however due to a perceived lack of time to wait for the prerequisite
> > cleanup to be merged, here they are all together.
> 
> net-next is already closed, sorry :(

Can you take patch 1, or would I have to resend that separately to "net"
after $n days?
patchwork-bot+netdevbpf@kernel.org Feb. 21, 2023, 5:20 p.m. UTC | #3 
Hello:

This series was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 20 Feb 2023 14:23:30 +0200 you wrote:
> 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/20220816222920.1952936-1-vladimir.oltean@nxp.com/
> 
> 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/20220816222920.1952936-3-vladimir.oltean@nxp.com/
> 
> [...]

Here is the summary with links:
  - [v3,net-next,01/13] net: ethtool: fix __ethtool_dev_mm_supported() implementation
    https://git.kernel.org/netdev/net-next/c/a00da30c052f
  - [v3,net-next,02/13] net: ethtool: create and export ethtool_dev_mm_supported()
    (no matching commit)
  - [v3,net-next,03/13] net/sched: mqprio: simplify handling of nlattr portion of TCA_OPTIONS
    (no matching commit)
  - [v3,net-next,04/13] net/sched: mqprio: add extack to mqprio_parse_nlattr()
    (no matching commit)
  - [v3,net-next,05/13] net/sched: mqprio: add an extack message to mqprio_parse_opt()
    (no matching commit)
  - [v3,net-next,06/13] net/sched: pass netlink extack to mqprio and taprio offload
    (no matching commit)
  - [v3,net-next,07/13] net/sched: mqprio: allow per-TC user input of FP adminStatus
    (no matching commit)
  - [v3,net-next,08/13] net/sched: taprio: allow per-TC user input of FP adminStatus
    (no matching commit)
  - [v3,net-next,09/13] net: enetc: rename "mqprio" to "qopt"
    (no matching commit)
  - [v3,net-next,10/13] net: mscc: ocelot: add support for mqprio offload
    (no matching commit)
  - [v3,net-next,11/13] net: dsa: felix: act upon the mqprio qopt in taprio offload
    (no matching commit)
  - [v3,net-next,12/13] net: mscc: ocelot: add support for preemptible traffic classes
    (no matching commit)
  - [v3,net-next,13/13] net: enetc: add support for preemptible traffic classes
    (no matching commit)

You are awesome, thank you!
Vladimir Oltean March 11, 2023, 9:56 p.m. UTC | #4 
On Mon, Feb 20, 2023 at 02:23:30PM +0200, 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).

Are there any comments before I resend this? So far I have no changes
planned for v4.
Simon Horman March 13, 2023, 3 p.m. UTC | #5 
On Sat, Mar 11, 2023 at 11:56:16PM +0200, Vladimir Oltean wrote:
> On Mon, Feb 20, 2023 at 02:23:30PM +0200, 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).
> 
> Are there any comments before I resend this? So far I have no changes
> planned for v4.

FWIIW, I am now reviewing v3 - I missed that only the first patch was
was applied when the message from patch bot arrived. So far I
am up to patch 08/13 and nothing stands out so far. And I can just as
easily review v4.
Simon Horman March 13, 2023, 3:51 p.m. UTC | #6 
On Mon, Mar 13, 2023 at 04:00:53PM +0100, Simon Horman wrote:
> On Sat, Mar 11, 2023 at 11:56:16PM +0200, Vladimir Oltean wrote:
> > On Mon, Feb 20, 2023 at 02:23:30PM +0200, 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).
> > 
> > Are there any comments before I resend this? So far I have no changes
> > planned for v4.
> 
> FWIIW, I am now reviewing v3 - I missed that only the first patch was
> was applied when the message from patch bot arrived. So far I
> am up to patch 08/13 and nothing stands out so far. And I can just as
> easily review v4.

FWIIW, I completed my review.

Reviewed-by: Simon Horman <simon.horman@corigine.com>