Re: [Bridge] [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface implementation
Hi Jiri On 01.10.2020 14:49, Jiri Pirko wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Thu, Oct 01, 2020 at 12:30:18PM CEST, henrik.bjoernl...@microchip.com wrote: This is the definition of the CFM switchdev interface. The interface consist of these objects: SWITCHDEV_OBJ_ID_MEP_CFM, SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM, SWITCHDEV_OBJ_ID_CC_CONFIG_CFM, SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM, SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM, SWITCHDEV_OBJ_ID_MEP_STATUS_CFM, SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM MEP instance add/del switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CFM) switchdev_port_obj_del(SWITCHDEV_OBJ_ID_MEP_CFM) MEP cofigure switchdev_port_obj_add(SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM) MEP CC cofigure switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CONFIG_CFM) Peer MEP add/del switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM) switchdev_port_obj_del(SWITCHDEV_OBJ_ID_CC_PEER_MEP_CFM) Start/stop CCM transmission switchdev_port_obj_add(SWITCHDEV_OBJ_ID_CC_CCM_TX_CFM) Get MEP status switchdev_port_obj_get(SWITCHDEV_OBJ_ID_MEP_STATUS_CFM) Get Peer MEP status switchdev_port_obj_get(SWITCHDEV_OBJ_ID_PEER_MEP_STATUS_CFM) Reviewed-by: Horatiu Vultur Signed-off-by: Henrik Bjoernlund You have to submit the driver parts as a part of this patchset. Otherwise it is no good. Fair enough. With MRP we did it like this, and after Nik asked for details on what is being offload, we thought that adding this would help. The reason why we did not include the implementation of this interface is that it is for a new SoC which is still not fully available which is why we have not done the basic SwitchDev driver for it yet. But the basic functionality clearly needs to come first. Our preference is to continue fixing the comments we got on the pure SW implementation and then get back to the SwitchDev offloading. This will mean dropping the last 2 patches in the serie. Does that work for you Jiri, and Nik? /Allan
Re: [Bridge] [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)
Hi, On 08.09.2020 11:04, Henrik Bjoernlund - M31679 wrote: On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote: The 09/04/2020 15:44, Stephen Hemminger wrote: > On Fri, 4 Sep 2020 09:15:20 + Henrik Bjoernlund > wrote: Hi, I also had the same initial thought - this really doesn't seem to affect the bridge in any way, it's only collecting and transmitting information. I get that you'd like to use the bridge as a passthrough device to switchdev to program your hw, could you share what would be offloaded more specifically ? Yes. The HW will offload the periodic sending of CCM frames, and the reception. If CCM frames are not received as expected, it will raise an interrupt. This means that all the functionality provided in this series will be offloaded to HW. The offloading is very important on our HW where we have a small CPU, serving many ports, with a high frequency of CFM frames. The HW also support Link-Trace and Loop-back, which we may come back to later. All you do - snooping and blocking these packets can easily be done from user- space with the help of ebtables, but since we need to have a software implementation/fallback of anything being offloaded via switchdev we might need this after all, I'd just prefer to push as much as possible to user-space. In addition to Henriks comment, it is worth mentioning that we are trying to push as much of the functionallity to user-space (learnings from the MRP discussions). This is why there are currently no in-kernel users of the CCM-lose singnal. When a CCM-defect is happening the network typically needs to be re-configured. This we are trying to keep in user-space. I plan to review the individual patches tomorrow. Thanks. /Allan
