Re: [RFC PATCH net-next 2/3] net: hsr: add DSA offloading support
From: Florian Fainelli <f.fainelli@gmail.com>
Date: 2021-01-22 18:11:33
On 1/22/2021 7:59 AM, George McCollister wrote:
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 hunk ↗ jump to hunk
--- 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.hdiff --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. [snip]
+static inline bool netif_is_hsr_master(const struct net_device *dev)
+{
+ return dev->flags & IFF_MASTER && dev->priv_flags & IFF_HSR;
+}
+
+static inline bool netif_is_hsr_slave(const struct net_device *dev)
+{
+ return dev->flags & IFF_SLAVE && dev->priv_flags & IFF_HSR;
+}I believe the kernel community is now trying to eliminate the use of the terms master and slave, can you replace these with some HSR specific naming maybe? -- Florian