| Message ID | 20201012140428.2549163-1-henrik.bjoernlund@microchip.com |
|---|---|
| Headers | show |
| Series | net: bridge: cfm: Add support for Connectivity Fault Management(CFM) | expand |
On Mon, 2020-10-12 at 14:04 +0000, Henrik Bjoernlund wrote: > This patch extends the processing of frames in the bridge. Currently MRP > frames needs special processing and the current implementation doesn't > allow a nice way to process different frame types. Therefore try to > improve this by adding a list that contains frame types that need > special processing. This list is iterated for each input frame and if > there is a match based on frame type then these functions will be called > and decide what to do with the frame. It can process the frame then the > bridge doesn't need to do anything or don't process so then the bridge > will do normal forwarding. > > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com> > Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> > --- > net/bridge/br_device.c | 1 + > net/bridge/br_input.c | 33 ++++++++++++++++++++++++++++++++- > net/bridge/br_mrp.c | 19 +++++++++++++++---- > net/bridge/br_private.h | 19 ++++++++++++------- > 4 files changed, 60 insertions(+), 12 deletions(-) > Looks good. Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
On Mon, 12 Oct 2020 14:04:18 +0000 Henrik Bjoernlund wrote: > Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14. > > Connectivity Fault Management (CFM) comprises capabilities for detecting, verifying, > and isolating connectivity failures in Virtual Bridged Networks. > These capabilities can be used in networks operated by multiple independent organizations, > each with restricted management access to each other’s equipment. Please wrap the cover letter and commit messages to 70 chars. > Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com> You have two spaces after the name in many tags.
On Mon, 12 Oct 2020 14:04:24 +0000 Henrik Bjoernlund wrote: > +struct br_cfm_status_tlv { > + __u8 type; > + __be16 length; > + __u8 value; > +}; This structure is unused (and likely not what you want, since it will have 2 1 byte while unless you mark length as __packed).
Thanks for your review. Regards Henrik The 10/14/2020 10:54, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Mon, 2020-10-12 at 14:04 +0000, Henrik Bjoernlund wrote: > > This is the implementation of CFM netlink configuration > > get information interface. > > > > Add new nested netlink attributes. These attributes are used by the > > user space to get configuration information. > > > > GETLINK: > > Request filter RTEXT_FILTER_CFM_CONFIG: > > Indicating that CFM configuration information must be delivered. > > > > IFLA_BRIDGE_CFM: > > Points to the CFM information. > > > > IFLA_BRIDGE_CFM_MEP_CREATE_INFO: > > This indicate that MEP instance create parameters are following. > > IFLA_BRIDGE_CFM_MEP_CONFIG_INFO: > > This indicate that MEP instance config parameters are following. > > IFLA_BRIDGE_CFM_CC_CONFIG_INFO: > > This indicate that MEP instance CC functionality > > parameters are following. > > IFLA_BRIDGE_CFM_CC_RDI_INFO: > > This indicate that CC transmitted CCM PDU RDI > > parameters are following. > > IFLA_BRIDGE_CFM_CC_CCM_TX_INFO: > > This indicate that CC transmitted CCM PDU parameters are > > following. > > IFLA_BRIDGE_CFM_CC_PEER_MEP_INFO: > > This indicate that the added peer MEP IDs are following. > > > > CFM nested attribute has the following attributes in next level. > > > > GETLINK RTEXT_FILTER_CFM_CONFIG: > > IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE: > > The created MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN: > > The created MEP domain. > > The type is u32 (br_cfm_domain). > > It must be BR_CFM_PORT. > > This means that CFM frames are transmitted and received > > directly on the port - untagged. Not in a VLAN. > > IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION: > > The created MEP direction. > > The type is u32 (br_cfm_mep_direction). > > It must be BR_CFM_MEP_DIRECTION_DOWN. > > This means that CFM frames are transmitted and received on > > the port. Not in the bridge. > > IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX: > > The created MEP residence port ifindex. > > The type is u32 (ifindex). > > > > IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE: > > The deleted MEP instance number. > > The type is u32. > > > > IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE: > > The configured MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC: > > The configured MEP unicast MAC address. > > The type is 6*u8 (array). > > This is used as SMAC in all transmitted CFM frames. > > IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL: > > The configured MEP unicast MD level. > > The type is u32. > > It must be in the range 1-7. > > No CFM frames are passing through this MEP on lower levels. > > IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID: > > The configured MEP ID. > > The type is u32. > > It must be in the range 0-0x1FFF. > > This MEP ID is inserted in any transmitted CCM frame. > > > > IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE: > > The configured MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE: > > The Continuity Check (CC) functionality is enabled or disabled. > > The type is u32 (bool). > > IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL: > > The CC expected receive interval of CCM frames. > > The type is u32 (br_cfm_ccm_interval). > > This is also the transmission interval of CCM frames when enabled. > > IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID: > > The CC expected receive MAID in CCM frames. > > The type is CFM_MAID_LENGTH*u8. > > This is MAID is also inserted in transmitted CCM frames. > > > > IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE: > > The configured MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_CC_PEER_MEPID: > > The CC Peer MEP ID added. > > The type is u32. > > When a Peer MEP ID is added and CC is enabled it is expected to > > receive CCM frames from that Peer MEP. > > > > IFLA_BRIDGE_CFM_CC_RDI_INSTANCE: > > The configured MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_CC_RDI_RDI: > > The RDI that is inserted in transmitted CCM PDU. > > The type is u32 (bool). > > > > IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE: > > The configured MEP instance number. > > The type is u32. > > IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC: > > The transmitted CCM frame destination MAC address. > > The type is 6*u8 (array). > > This is used as DMAC in all transmitted CFM frames. > > IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE: > > The transmitted CCM frame update (increment) of sequence > > number is enabled or disabled. > > The type is u32 (bool). > > IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD: > > The period of time where CCM frame are transmitted. > > The type is u32. > > The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX > > must be done before timeout to keep transmission alive. > > When period is zero any ongoing CCM frame transmission > > will be stopped. > > IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV: > > The transmitted CCM frame update with Interface Status TLV > > is enabled or disabled. > > The type is u32 (bool). > > IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE: > > The transmitted Interface Status TLV value field. > > The type is u8. > > IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV: > > The transmitted CCM frame update with Port Status TLV is enabled > > or disabled. > > The type is u32 (bool). > > IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE: > > The transmitted Port Status TLV value field. > > The type is u8. > > > > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com> > > Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > --- > > include/uapi/linux/if_bridge.h | 6 ++ > > net/bridge/br_cfm_netlink.c | 161 +++++++++++++++++++++++++++++++++ > > net/bridge/br_netlink.c | 29 +++++- > > net/bridge/br_private.h | 6 ++ > > 4 files changed, 200 insertions(+), 2 deletions(-) > > > > Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> > >
Thanks for your review. Comments below. Regards Henrik The 10/14/2020 16:16, Jakub Kicinski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Mon, 12 Oct 2020 14:04:24 +0000 Henrik Bjoernlund wrote: > > +struct br_cfm_status_tlv { > > + __u8 type; > > + __be16 length; > > + __u8 value; > > +}; > > This structure is unused (and likely not what you want, since it will > have 2 1 byte while unless you mark length as __packed). I have changed as requested.
Thanks for your review. Comments below. Regards Henrik The 10/14/2020 15:58, Jakub Kicinski wrote:> > On Mon, 12 Oct 2020 14:04:18 +0000 Henrik Bjoernlund wrote: > > Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14. > > > > Connectivity Fault Management (CFM) comprises capabilities for detecting, verifying, > > and isolating connectivity failures in Virtual Bridged Networks. > > These capabilities can be used in networks operated by multiple independent organizations, > > each with restricted management access to each other’s equipment. > > Please wrap the cover letter and commit messages to 70 chars. > I will do that, > > Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com> > > You have two spaces after the name in many tags. I will change as requested.
Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14. Connectivity Fault Management (CFM) comprises capabilities for detecting, verifying, and isolating connectivity failures in Virtual Bridged Networks. These capabilities can be used in networks operated by multiple independent organizations, each with restricted management access to each other’s equipment. CFM functions are partitioned as follows: — Path discovery — Fault detection — Fault verification and isolation — Fault notification — Fault recovery The primary CFM protocol shims are called Maintenance Points (MPs). A MP can be either a MEP or a MHF. The MEP: -It is the Maintenance association End Point described in 802.1Q section 19.2. -It is created on a specific level (1-7) and is assuring that no CFM frames are passing through this MEP on lower levels. -It initiates and terminates/validates CFM frames on its level. -It can only exist on a port that is related to a bridge. The MHF: -It is the Maintenance Domain Intermediate Point (MIP) Half Function (MHF) described in 802.1Q section 19.3. -It is created on a specific level (1-7). -It is extracting/injecting certain CFM frame on this level. -It can only exist on a port that is related to a bridge. -Currently not supported. There are defined the following CFM protocol functions: -Continuity Check -Loopback. Currently not supported. -Linktrace. Currently not supported. This CFM component supports create/delete of MEP instances and configuration of the different CFM protocols. Also status information can be fetched and delivered through notification due to defect status change. The user interacts with CFM using the 'cfm' user space client program, the client talks with the kernel using netlink. Any notification emitted by CFM from the kernel can be monitored in user space by starting 'cfm_server' program. Currently this 'cfm' and 'cfm_server' programs are standalone placed in a cfm repository https://github.com/microchip-ung/cfm but it is considered to integrate this into 'iproute2'. v1 -> v2 Added the CFM switchdev interface and also added utilization by calling the interface from the kernel CFM implementation trying to offload CFM functionality to HW. This offload (CFM driver) is currently not implemented. Corrections based on RCF comments: -The single CFM kernel implementation Patch is broken up into three patches. -Changed the list of MEP instances from list_head to hlist_head. -Removed unnecessary RCU list traversing. -Solved RCU unlocking problem. -Removed unnecessary comments. -Added ASSERT_RTNL() where required. -Shaping up on error messages. -Correction NETLINK br_fill_ifinfo() to be able to handle 'filter_mask' with multiple flags asserted. v2 -> v3 The switchdev definition and utilization has been removed as there was no switchdev implementation. Some compiling issues are fixed as Reported-by: kernel test robot <lkp@intel.com>. v3 -> v4 Fixed potential crash during hlist walk where elements are removed. Giving all commits unique titles. NETLINK implementation split into three commits. Commit "bridge: cfm: Bridge port remove" is merged with commit "bridge: cfm: Kernel space implementation of CFM. MEP create/delete." v4 -> v5 Reordered members in struct net_bridge to bring member frame_type_list to the first cache line. Helper functions nla_get_mac() and nla_get_maid() are removed. The NLA_POLICY_NESTED() macro is used to initialize the br_cfm_policy array. Fixed reverse xmas tree. Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@microchip.com> Henrik Bjoernlund (10): net: bridge: extend the process of special frames bridge: cfm: Add BRIDGE_CFM to Kconfig. bridge: uapi: cfm: Added EtherType used by the CFM protocol. bridge: cfm: Kernel space implementation of CFM. MEP create/delete. bridge: cfm: Kernel space implementation of CFM. CCM frame TX added. bridge: cfm: Kernel space implementation of CFM. CCM frame RX added. bridge: cfm: Netlink SET configuration Interface. bridge: cfm: Netlink GET configuration Interface. bridge: cfm: Netlink GET status Interface. bridge: cfm: Netlink Notifications. include/uapi/linux/cfm_bridge.h | 70 +++ include/uapi/linux/if_bridge.h | 125 +++++ include/uapi/linux/if_ether.h | 1 + include/uapi/linux/rtnetlink.h | 2 + net/bridge/Kconfig | 11 + net/bridge/Makefile | 2 + net/bridge/br_cfm.c | 884 ++++++++++++++++++++++++++++++++ net/bridge/br_cfm_netlink.c | 726 ++++++++++++++++++++++++++ net/bridge/br_device.c | 4 + net/bridge/br_if.c | 1 + net/bridge/br_input.c | 33 +- net/bridge/br_mrp.c | 19 +- net/bridge/br_netlink.c | 115 ++++- net/bridge/br_private.h | 77 ++- net/bridge/br_private_cfm.h | 147 ++++++ 15 files changed, 2194 insertions(+), 23 deletions(-) create mode 100644 include/uapi/linux/cfm_bridge.h create mode 100644 net/bridge/br_cfm.c create mode 100644 net/bridge/br_cfm_netlink.c create mode 100644 net/bridge/br_private_cfm.h