Re: [RFC PATCH net-next 2/3] net: hsr: add DSA offloading support

On 1/22/2021 9:56 AM, Florian Fainelli wrote:

On 1/22/2021 7:59 AM, George McCollister wrote:

quoted

Add support for offloading of HSR/PRP (IEC 62439-3) tag insertion
tag removal, duplicate generation and forwarding on DSA switches.

Use a new netdev_priv_flag IFF_HSR to indicate that a device is an HSR
device so DSA can tell them apart from other devices in
dsa_slave_changeupper.

Add DSA_NOTIFIER_HSR_JOIN and DSA_NOTIFIER_HSR_LEAVE which trigger calls
to .port_hsr_join and .port_hsr_leave in the DSA driver for the switch.

The DSA switch driver should then set netdev feature flags for the
HSR/PRP operation that it offloads.
    NETIF_F_HW_HSR_TAG_INS
    NETIF_F_HW_HSR_TAG_RM
    NETIF_F_HW_HSR_FWD
    NETIF_F_HW_HSR_DUP

For HSR, insertion involves the switch adding a 6 byte HSR header after
the 14 byte Ethernet header. For PRP it adds a 6 byte trailer.

Tag removal involves automatically stripping the HSR/PRP header/trailer
in the switch. This is possible when the switch also preforms auto
deduplication using the HSR/PRP header/trailer (making it no longer
required).

Forwarding involves automatically forwarding between redundant ports in
an HSR. This is crucial because delay is accumulated as a frame passes
through each node in the ring.

Duplication involves the switch automatically sending a single frame
from the CPU port to both redundant ports. This is required because the
inserted HSR/PRP header/trailer must contain the same sequence number
on the frames sent out both redundant ports.

Signed-off-by: George McCollister <george.mccollister@gmail.com>

This is just a high level overview for now, but I would split this into two:

- a patch that adds HSR offload to the existing HSR stack and introduces
the new netdev_features_t bits to support HSR offload, more on that below

- a patch that does the plumbing between HSR and within the DSA framework

quoted

---
 Documentation/networking/netdev-features.rst | 20 ++++++++++++++++
 include/linux/if_hsr.h                       | 22 ++++++++++++++++++
 include/linux/netdev_features.h              |  9 ++++++++
 include/linux/netdevice.h                    | 13 +++++++++++
 include/net/dsa.h                            | 13 +++++++++++
 net/dsa/dsa_priv.h                           | 11 +++++++++
 net/dsa/port.c                               | 34 ++++++++++++++++++++++++++++
 net/dsa/slave.c                              | 13 +++++++++++
 net/dsa/switch.c                             | 24 ++++++++++++++++++++
 net/ethtool/common.c                         |  4 ++++
 net/hsr/hsr_device.c                         | 12 +++-------
 net/hsr/hsr_forward.c                        | 27 +++++++++++++++++++---
 net/hsr/hsr_forward.h                        |  1 +
 net/hsr/hsr_main.c                           | 14 ++++++++++++
 net/hsr/hsr_main.h                           |  8 +------
 net/hsr/hsr_slave.c                          | 13 +++++++----
 16 files changed, 215 insertions(+), 23 deletions(-)
 create mode 100644 include/linux/if_hsr.h

diff --git a/Documentation/networking/netdev-features.rst b/Documentation/networking/netdev-features.rst
index a2d7d7160e39..4eab45405031 100644
--- a/Documentation/networking/netdev-features.rst
+++ b/Documentation/networking/netdev-features.rst

@@ -182,3 +182,23 @@ stricter than Hardware LRO.  A packet stream merged by Hardware GRO must
 be re-segmentable by GSO or TSO back to the exact original packet stream.
 Hardware GRO is dependent on RXCSUM since every packet successfully merged
 by hardware must also have the checksum verified by hardware.
+
+* hsr-tag-ins-offload
+
+This should be set for devices which insert an HSR (highspeed ring) tag
+automatically when in HSR mode.
+
+* hsr-tag-rm-offload
+
+This should be set for devices which remove HSR (highspeed ring) tags
+automatically when in HSR mode.
+
+* hsr-fwd-offload
+
+This should be set for devices which forward HSR (highspeed ring) frames from
+one port to another in hardware.
+
+* hsr-dup-offload
+
+This should be set for devices which duplicate outgoing HSR (highspeed ring)
+frames in hardware.

Do you think we can start with a hsr-hw-offload feature and create new
bits to described how challenged a device may be with HSR offload? Is it
 reasonable assumption that functional hardware should be able to
offload all of these functions or none of them?

It may be a good idea to know what the platform that Murali is working
on or has worked on is capable of doing, too.

Murali's email address is bouncing, adding Grygorii, Kishon and
Nishanth, they may know.
-- 
Florian