[v2,net-next,00/12] ethtool support for IEEE 802.3 MAC Merge layer

Message

Vladimir Oltean Jan. 11, 2023, 4:16 p.m. UTC

This is a continuation of my work started here:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/

I've decided to focus just on the MAC Merge layer for now, which is why
I am able to submit this patch set as non-RFC.

What is being introduced
------------------------

TL;DR: a MAC Merge layer as defined by IEEE 802.3-2018, clause 99
(interspersing of express traffic). This is controlled through ethtool
netlink (ETHTOOL_MSG_MM_GET, ETHTOOL_MSG_MM_SET). The raw ethtool
commands are posted here:
https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/

The MAC Merge layer has its own statistics counters
(ethtool --include-statistics --show-mm swp0) as well as two member
MACs, the statistics of which can be queried individually, through a new
ethtool netlink attribute, corresponding to:

$ ethtool -I --show-pause eno2 --src aggregate
$ ethtool -S eno2 --groups eth-mac eth-phy eth-ctrl rmon -- --src pmac

The core properties of the MAC Merge layer are described in great detail
in patches 02/12 and 03/12. They can be viewed in "make htmldocs" format.

Devices for which the API is supported
--------------------------------------

I decided to start with the Ethernet switch on NXP LS1028A (Felix)
because of the smaller patch set. I also have support for the ENETC
controller pending.

I would like to get confirmation that the UAPI being proposed here will
not restrict any use cases known by other hardware vendors.

Why is support for preemptible traffic classes not here?
--------------------------------------------------------

There is legitimate concern whether the 802.1Q portion of the standard
(which traffic classes go to the eMAC and which to the pMAC) should be
modeled in Linux using tc or using another UAPI. I think that is
stalling the entire series, but should be discussed separately instead.
Removing FP adminStatus support makes me confident enough to submit this
patch set without an RFC tag (meaning: I wouldn't mind if it was merged
as is).

What is submitted here is sufficient for an LLDP daemon to do its job.
I've patched openlldp to advertise and configure frame preemption:
https://github.com/vladimiroltean/openlldp/tree/frame-preemption-v3

In case someone wants to try it out, here are some commands I've used.

 # Configure the interfaces to receive and transmit LLDP Data Units
 lldptool -L -i eno0 adminStatus=rxtx
 lldptool -L -i swp0 adminStatus=rxtx
 # Enable the transmission of certain TLVs on switch's interface
 lldptool -T -i eno0 -V addEthCap enableTx=yes
 lldptool -T -i swp0 -V addEthCap enableTx=yes
 # Query LLDP statistics on switch's interface
 lldptool -S -i swp0
 # Query the received neighbor TLVs
 lldptool -i swp0 -t -n -V addEthCap
 Additional Ethernet Capabilities TLV
         Preemption capability supported
         Preemption capability enabled
         Preemption capability active
         Additional fragment size: 60 octets

So using this patch set, lldpad will be able to advertise and configure
frame preemption, but still, no data packet will be sent as preemptible
over the link, because there is no UAPI to control which traffic classes
are sent as preemptible and which as express.

Preemptable or preemptible?
---------------------------

IEEE 802.3 uses "preemptable" throughout. IEEE 802.1Q uses "preemptible"
throughout. Because the definition of "preemptible" falls under 802.1Q's
jurisdiction and 802.3 just references it, I went with the 802.1Q naming
even where supporting an 802.3 feature. Also, checkpatch agrees with this.

Vladimir Oltean (12):
  net: ethtool: netlink: introduce ethnl_update_bool()
  net: ethtool: add support for MAC Merge layer
  docs: ethtool-netlink: document interface for MAC Merge layer
  net: ethtool: netlink: retrieve stats from multiple sources (eMAC,
    pMAC)
  docs: ethtool: document ETHTOOL_A_STATS_SRC and
    ETHTOOL_A_PAUSE_STATS_SRC
  net: ethtool: add helpers for aggregate statistics
  net: ethtool: add helpers for MM addFragSize translation
  net: dsa: add plumbing for changing and getting MAC merge layer state
  net: mscc: ocelot: allow ocelot_stat_layout elements with no name
  net: mscc: ocelot: hide access to ocelot_stats_layout behind a helper
  net: mscc: ocelot: export ethtool MAC Merge stats for Felix VSC9959
  net: mscc: ocelot: add MAC Merge layer support for VSC9959

 Documentation/networking/ethtool-netlink.rst | 123 +++++++
 Documentation/networking/statistics.rst      |   1 +
 drivers/net/dsa/ocelot/felix.c               |  28 ++
 drivers/net/dsa/ocelot/felix_vsc9959.c       |  57 +++-
 drivers/net/ethernet/mscc/Makefile           |   1 +
 drivers/net/ethernet/mscc/ocelot.c           |  18 +-
 drivers/net/ethernet/mscc/ocelot.h           |   2 +
 drivers/net/ethernet/mscc/ocelot_mm.c        | 213 ++++++++++++
 drivers/net/ethernet/mscc/ocelot_stats.c     | 331 +++++++++++++++++--
 include/linux/ethtool.h                      | 245 +++++++++++---
 include/net/dsa.h                            |  11 +
 include/soc/mscc/ocelot.h                    |  58 ++++
 include/soc/mscc/ocelot_dev.h                |  23 ++
 include/uapi/linux/ethtool.h                 |  43 +++
 include/uapi/linux/ethtool_netlink.h         |  50 +++
 net/dsa/slave.c                              |  35 ++
 net/ethtool/Makefile                         |   4 +-
 net/ethtool/common.h                         |   2 +
 net/ethtool/mm.c                             | 273 +++++++++++++++
 net/ethtool/netlink.c                        |  19 ++
 net/ethtool/netlink.h                        |  34 +-
 net/ethtool/pause.c                          |  47 +++
 net/ethtool/stats.c                          | 158 ++++++++-
 23 files changed, 1697 insertions(+), 79 deletions(-)
 create mode 100644 drivers/net/ethernet/mscc/ocelot_mm.c
 create mode 100644 net/ethtool/mm.c

Comments

Vladimir Oltean Jan. 12, 2023, 11:29 a.m. UTC | #1

On Wed, Jan 11, 2023 at 06:16:54PM +0200, Vladimir Oltean wrote:
> This is a continuation of my work started here:
> https://patchwork.kernel.org/project/netdevbpf/cover/[e-mail]/
> 
> I've decided to focus just on the MAC Merge layer for now, which is why
> I am able to submit this patch set as non-RFC.

As it happens, this patch set seems to conflict with the recently merged
8580e16c28f3 ("net/ethtool: add netlink interface for the PLCA RS").
It is still possible to apply and test on a set of kernel UAPI headers
prior to that commit, so I will leave reviewers/testers more time to
comment, and will not resend kernel + user space patches just for this
fact.