From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3877C32771 for ; Fri, 24 Jan 2020 16:19:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8C582070A for ; Fri, 24 Jan 2020 16:19:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389636AbgAXQTc (ORCPT ); Fri, 24 Jan 2020 11:19:32 -0500 Received: from esa6.microchip.iphmx.com ([216.71.154.253]:25554 "EHLO esa6.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387404AbgAXQTa (ORCPT ); Fri, 24 Jan 2020 11:19:30 -0500 Received-SPF: Pass (esa6.microchip.iphmx.com: domain of Horatiu.Vultur@microchip.com designates 198.175.253.82 as permitted sender) identity=mailfrom; client-ip=198.175.253.82; receiver=esa6.microchip.iphmx.com; envelope-from="Horatiu.Vultur@microchip.com"; x-sender="Horatiu.Vultur@microchip.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 mx a:ushub1.microchip.com a:smtpout.microchip.com -exists:%{i}.spf.microchip.iphmx.com include:servers.mcsv.net include:mktomail.com include:spf.protection.outlook.com ~all" Received-SPF: None (esa6.microchip.iphmx.com: no sender authenticity information available from domain of postmaster@email.microchip.com) identity=helo; client-ip=198.175.253.82; receiver=esa6.microchip.iphmx.com; envelope-from="Horatiu.Vultur@microchip.com"; x-sender="postmaster@email.microchip.com"; x-conformance=spf_only Authentication-Results: esa6.microchip.iphmx.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=Horatiu.Vultur@microchip.com; spf=None smtp.helo=postmaster@email.microchip.com; dmarc=pass (p=none dis=none) d=microchip.com IronPort-SDR: l8CyMfs9VCFSVcsvvQzBglwOP4WuxccVIKygyaKACruS/fEFc6/ZHLzLuWRZcj3hOx+JQvqLM7 FGTuaME6+iwR1EPmOlVkp76SZlCSVz44V8wi9u3fRuXGuHBdlORxGoCNtKx/ZTVbUzPybz10+f 0vgzt4VyNZfIT/IhCT10ycWei3Su4l+odEsg0CzviTbKAayKNu9nKxkYEXxFTugIJgjGan9uyS 9RKPtWYt9Or+NEfZ3WBshrw2X9u0dVbR8rAs+iQy/FYY1KMI2UPs8fvnHP9lfB6GynNx4JGwl3 78w= X-IronPort-AV: E=Sophos;i="5.70,358,1574146800"; d="scan'208";a="19285" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 24 Jan 2020 09:19:28 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 24 Jan 2020 09:19:28 -0700 Received: from soft-dev3.microsemi.net (10.10.85.251) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Fri, 24 Jan 2020 09:19:26 -0700 From: Horatiu Vultur To: , , , , , , , , , , , , CC: Horatiu Vultur Subject: [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) Date: Fri, 24 Jan 2020 17:18:18 +0100 Message-ID: <20200124161828.12206-1-horatiu.vultur@microchip.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Media Redundancy Protocol is a data network protocol standardized by International Electrotechnical Commission as IEC 62439-2. It allows rings of Ethernet switches to overcome any single failure with recovery time faster than STP. It is primarily used in Industrial Ethernet applications. Based on the previous RFC[1][2], the MRP state machine and all the timers were moved to userspace. A generic netlink interface is added to allow configuring the HW, and logic added to to implement the MRP specific forwarding rules. The userspace application that is using the new netlink can be found here[3]. The current implementation both in kernel and userspace supports only 2 roles: MRM - this one is responsible to send MRP_Test and MRP_Topo frames on both ring ports. It needs to process MRP_Test to know if the ring is open or closed. This operation is desired to be offloaded to the HW because it requires to generate and process up to 4000 frames per second. Whenever it detects that the ring open it sends MRP_Topo frames to notify all MRC about changes in the topology. MRM needs also to process MRP_LinkChange frames, these frames are generated by the MRC. When the ring is open the the state of both ports is to forward frames and when the ring is closed then the secondary port is blocked. MRC - this one is responsible to forward MRP frames between the ring ports. In case one of the ring ports gets a link down or up, then MRC will generate a MRP_LinkChange frames. This node should also process MRP_Topo frames and to clear its FDB when it receives this frame. Userspace Deamon +----------+ Client + | +--------------|-----------------------------------------+ Kernel | + Netlink | + Interrupt | | +--------------|------------------------------|----------+ HW | Switchdev | + | The user interacts using the client (called 'mrp'), the client talks to the deamon (called 'mrp_server'), which talks with the kernel using netlink. The kernel will try to offload the requests to the HW via switchdev API. For this a new generic netlink interface was added to the bridge. If the kernel cannot offload MRP to HW (maybe it does not have a switchdev driver, or it is just not supported), then all the netlink calls will return -EOPNOTSUPP. In this case the user-space deamon fallback to SW only implementation. There are required changes to the SW bridge to be able to run the MRP. First the bridge needs to initialize the netlink interface. And second it needs to know if a MRP frame was received on a MRP ring port. In case it was received the SW bridge should not forward the frame it needs to redirected to upper layes. In case it was not received on a ring port then it just forwards it as usual. To be able to offload this to the HW, it was required to extend the switchdev API. If this will be accepted then in the future the netlink interface can be expended with multiple attributes which are required by different roles of the MRP. Like Media Redundancy Automanager(MRA), Media Interconnect Manager(MIM) and Media Interconnect Client(MIC). [1] https://www.spinics.net/lists/netdev/msg623647.html [2] https://www.spinics.net/lists/netdev/msg624378.html [3] https://github.com/microchip-ung/mrp/tree/patch-v3 Horatiu Vultur (10): net: bridge: mrp: Expose mrp attributes. net: bridge: mrp: Expose function br_mrp_port_open net: bridge: mrp: Add MRP interface used by netlink net: bridge: mrp: Add generic netlink interface to configure MRP net: bridge: mrp: Update MRP interface to add switchdev support net: bridge: mrp: switchdev: Extend switchdev API to offload MRP net: bridge: mrp: switchdev: Implement MRP API for switchdev net: bridge: mrp: Connect MRP api with the switchev API net: bridge: mrp: Integrate MRP into the bridge net: bridge: mrp: Update Kconfig and Makefile include/linux/mrp_bridge.h | 25 ++ include/net/switchdev.h | 51 +++ include/uapi/linux/if_ether.h | 1 + include/uapi/linux/mrp_bridge.h | 118 ++++++ net/bridge/Kconfig | 12 + net/bridge/Makefile | 2 + net/bridge/br.c | 11 + net/bridge/br_device.c | 3 + net/bridge/br_if.c | 6 + net/bridge/br_input.c | 14 + net/bridge/br_mrp.c | 193 ++++++++++ net/bridge/br_mrp_netlink.c | 655 ++++++++++++++++++++++++++++++++ net/bridge/br_mrp_switchdev.c | 147 +++++++ net/bridge/br_private.h | 14 + net/bridge/br_private_mrp.h | 58 +++ 15 files changed, 1310 insertions(+) create mode 100644 include/linux/mrp_bridge.h create mode 100644 include/uapi/linux/mrp_bridge.h create mode 100644 net/bridge/br_mrp.c create mode 100644 net/bridge/br_mrp_netlink.c create mode 100644 net/bridge/br_mrp_switchdev.c create mode 100644 net/bridge/br_private_mrp.h -- 2.17.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Horatiu Vultur Date: Fri, 24 Jan 2020 17:18:18 +0100 Message-ID: <20200124161828.12206-1-horatiu.vultur@microchip.com> MIME-Version: 1.0 Content-Type: text/plain Subject: [Bridge] [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP) List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, jiri@resnulli.us, ivecera@redhat.com, davem@davemloft.net, roopa@cumulusnetworks.com, nikolay@cumulusnetworks.com, anirudh.venkataramanan@intel.com, olteanv@gmail.com, andrew@lunn.ch, jeffrey.t.kirsher@intel.com, UNGLinuxDriver@microchip.com Cc: Horatiu Vultur Media Redundancy Protocol is a data network protocol standardized by International Electrotechnical Commission as IEC 62439-2. It allows rings of Ethernet switches to overcome any single failure with recovery time faster than STP. It is primarily used in Industrial Ethernet applications. Based on the previous RFC[1][2], the MRP state machine and all the timers were moved to userspace. A generic netlink interface is added to allow configuring the HW, and logic added to to implement the MRP specific forwarding rules. The userspace application that is using the new netlink can be found here[3]. The current implementation both in kernel and userspace supports only 2 roles: MRM - this one is responsible to send MRP_Test and MRP_Topo frames on both ring ports. It needs to process MRP_Test to know if the ring is open or closed. This operation is desired to be offloaded to the HW because it requires to generate and process up to 4000 frames per second. Whenever it detects that the ring open it sends MRP_Topo frames to notify all MRC about changes in the topology. MRM needs also to process MRP_LinkChange frames, these frames are generated by the MRC. When the ring is open the the state of both ports is to forward frames and when the ring is closed then the secondary port is blocked. MRC - this one is responsible to forward MRP frames between the ring ports. In case one of the ring ports gets a link down or up, then MRC will generate a MRP_LinkChange frames. This node should also process MRP_Topo frames and to clear its FDB when it receives this frame. Userspace Deamon +----------+ Client + | +--------------|-----------------------------------------+ Kernel | + Netlink | + Interrupt | | +--------------|------------------------------|----------+ HW | Switchdev | + | The user interacts using the client (called 'mrp'), the client talks to the deamon (called 'mrp_server'), which talks with the kernel using netlink. The kernel will try to offload the requests to the HW via switchdev API. For this a new generic netlink interface was added to the bridge. If the kernel cannot offload MRP to HW (maybe it does not have a switchdev driver, or it is just not supported), then all the netlink calls will return -EOPNOTSUPP. In this case the user-space deamon fallback to SW only implementation. There are required changes to the SW bridge to be able to run the MRP. First the bridge needs to initialize the netlink interface. And second it needs to know if a MRP frame was received on a MRP ring port. In case it was received the SW bridge should not forward the frame it needs to redirected to upper layes. In case it was not received on a ring port then it just forwards it as usual. To be able to offload this to the HW, it was required to extend the switchdev API. If this will be accepted then in the future the netlink interface can be expended with multiple attributes which are required by different roles of the MRP. Like Media Redundancy Automanager(MRA), Media Interconnect Manager(MIM) and Media Interconnect Client(MIC). [1] https://www.spinics.net/lists/netdev/msg623647.html [2] https://www.spinics.net/lists/netdev/msg624378.html [3] https://github.com/microchip-ung/mrp/tree/patch-v3 Horatiu Vultur (10): net: bridge: mrp: Expose mrp attributes. net: bridge: mrp: Expose function br_mrp_port_open net: bridge: mrp: Add MRP interface used by netlink net: bridge: mrp: Add generic netlink interface to configure MRP net: bridge: mrp: Update MRP interface to add switchdev support net: bridge: mrp: switchdev: Extend switchdev API to offload MRP net: bridge: mrp: switchdev: Implement MRP API for switchdev net: bridge: mrp: Connect MRP api with the switchev API net: bridge: mrp: Integrate MRP into the bridge net: bridge: mrp: Update Kconfig and Makefile include/linux/mrp_bridge.h | 25 ++ include/net/switchdev.h | 51 +++ include/uapi/linux/if_ether.h | 1 + include/uapi/linux/mrp_bridge.h | 118 ++++++ net/bridge/Kconfig | 12 + net/bridge/Makefile | 2 + net/bridge/br.c | 11 + net/bridge/br_device.c | 3 + net/bridge/br_if.c | 6 + net/bridge/br_input.c | 14 + net/bridge/br_mrp.c | 193 ++++++++++ net/bridge/br_mrp_netlink.c | 655 ++++++++++++++++++++++++++++++++ net/bridge/br_mrp_switchdev.c | 147 +++++++ net/bridge/br_private.h | 14 + net/bridge/br_private_mrp.h | 58 +++ 15 files changed, 1310 insertions(+) create mode 100644 include/linux/mrp_bridge.h create mode 100644 include/uapi/linux/mrp_bridge.h create mode 100644 net/bridge/br_mrp.c create mode 100644 net/bridge/br_mrp_netlink.c create mode 100644 net/bridge/br_mrp_switchdev.c create mode 100644 net/bridge/br_private_mrp.h -- 2.17.1