All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org" 
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Cc: "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [net-next v2 07/11] bridge: cfm: Netlink Interface.
Date: Tue, 6 Oct 2020 14:44:31 +0000	[thread overview]
Message-ID: <056628d19fcd58c88e084d14ca063204b006f8a4.camel@nvidia.com> (raw)
In-Reply-To: <20201001103019.1342470-8-henrik.bjoernlund@microchip.com>

On Thu, 2020-10-01 at 10:30 +0000, Henrik Bjoernlund wrote:
> This is the implementation of CFM netlink configuration
> and status information interface.
> 
> Add new nested netlink attributes. These attributes are used by the
> user space to create/delete/configure CFM instances and get status.
> Also they are used by the kernel to notify the user space when changes
> in any status happens.
> 
> SETLINK:
>     IFLA_BRIDGE_CFM:
>         Indicate that the following attributes are CFM.
> 
>     IFLA_BRIDGE_CFM_MEP_CREATE:
>         This indicate that a MEP instance must be created.
>     IFLA_BRIDGE_CFM_MEP_DELETE:
>         This indicate that a MEP instance must be deleted.
>     IFLA_BRIDGE_CFM_MEP_CONFIG:
>         This indicate that a MEP instance must be configured.
>     IFLA_BRIDGE_CFM_CC_CONFIG:
>         This indicate that a MEP instance Continuity Check (CC)
>         functionality must be configured.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD:
>         This indicate that a CC Peer MEP must be added.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE:
>         This indicate that a CC Peer MEP must be removed.
>     IFLA_BRIDGE_CFM_CC_CCM_TX:
>         This indicate that the CC transmitted CCM PDU must be configured.
>     IFLA_BRIDGE_CFM_CC_RDI:
>         This indicate that the CC transmitted CCM PDU RDI must be
>         configured.
> 
> 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.
> 
>     Request filter RTEXT_FILTER_CFM_STATUS:
>     Indicating that CFM status information must be delivered.
> 
>     IFLA_BRIDGE_CFM:
>         Points to the CFM information.
> 
>     IFLA_BRIDGE_CFM_MEP_STATUS_INFO:
>         This indicate that the MEP instance status are following.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO:
>         This indicate that the peer MEP status are following.
> 
> CFM nested attribute has the following attributes in next level.
> 
> SETLINK and 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.
> 
> GETLINK RTEXT_FILTER_CFM_STATUS:
>     IFLA_BRIDGE_CFM_MEP_STATUS_INSTANCE:
>         The MEP instance number of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_STATUS_OPCODE_UNEXP_SEEN:
>         The MEP instance received CFM PDU with unexpected Opcode.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_MEP_STATUS_VERSION_UNEXP_SEEN:
>         The MEP instance received CFM PDU with unexpected version.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_MEP_STATUS_RX_LEVEL_LOW_SEEN:
>         The MEP instance received CCM PDU with MD level lower than
>         configured level. This frame is discarded.
>         The type is u32 (bool).
> 
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_INSTANCE:
>         The MEP instance number of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_PEER_MEPID:
>         The added Peer MEP ID of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_CCM_DEFECT:
>         The CCM defect status.
>         The type is u32 (bool).
>         True means no CCM frame is received for 3.25 intervals.
>         IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_RDI:
>         The last received CCM PDU RDI.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_PORT_TLV_VALUE:
>         The last received CCM PDU Port Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_IF_TLV_VALUE:
>         The last received CCM PDU Interface Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEEN:
>         A CCM frame has been received from Peer MEP.
>         The type is u32 (bool).
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_TLV_SEEN:
>         A CCM frame with TLV has been received from Peer MEP.
>         The type is u32 (bool).
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEQ_UNEXP_SEEN:
>         A CCM frame with unexpected sequence number has been received
>         from Peer MEP.
>         The type is u32 (bool).
>         When a sequence number is not one higher than previously received
>         then it is unexpected.
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
> 
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> ---
>  include/uapi/linux/if_bridge.h | 125 ++++++
>  include/uapi/linux/rtnetlink.h |   2 +
>  net/bridge/Makefile            |   2 +-
>  net/bridge/br_cfm.c            |   5 +
>  net/bridge/br_cfm_netlink.c    | 724 +++++++++++++++++++++++++++++++++
>  net/bridge/br_netlink.c        |  67 ++-
>  net/bridge/br_private.h        |  31 ++
>  7 files changed, 940 insertions(+), 16 deletions(-)
>  create mode 100644 net/bridge/br_cfm_netlink.c
> 

Hi Henrik,
This patch definitely can be broken into a few smaller ones that add support for
configuring/dumping different cfm parts.

Also, and more importantly, the IFLA_AF_SPEC fix must go to -net as a separate
patch since the problem is there even now. After it gets accepted and -net is
merged into net-next you can rebase on top of it.

Thanks,
 Nik



WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "bridge@lists.linux-foundation.org"
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Cc: "horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Subject: Re: [Bridge] [net-next v2 07/11] bridge: cfm: Netlink Interface.
Date: Tue, 6 Oct 2020 14:44:31 +0000	[thread overview]
Message-ID: <056628d19fcd58c88e084d14ca063204b006f8a4.camel@nvidia.com> (raw)
In-Reply-To: <20201001103019.1342470-8-henrik.bjoernlund@microchip.com>

On Thu, 2020-10-01 at 10:30 +0000, Henrik Bjoernlund wrote:
> This is the implementation of CFM netlink configuration
> and status information interface.
> 
> Add new nested netlink attributes. These attributes are used by the
> user space to create/delete/configure CFM instances and get status.
> Also they are used by the kernel to notify the user space when changes
> in any status happens.
> 
> SETLINK:
>     IFLA_BRIDGE_CFM:
>         Indicate that the following attributes are CFM.
> 
>     IFLA_BRIDGE_CFM_MEP_CREATE:
>         This indicate that a MEP instance must be created.
>     IFLA_BRIDGE_CFM_MEP_DELETE:
>         This indicate that a MEP instance must be deleted.
>     IFLA_BRIDGE_CFM_MEP_CONFIG:
>         This indicate that a MEP instance must be configured.
>     IFLA_BRIDGE_CFM_CC_CONFIG:
>         This indicate that a MEP instance Continuity Check (CC)
>         functionality must be configured.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD:
>         This indicate that a CC Peer MEP must be added.
>     IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE:
>         This indicate that a CC Peer MEP must be removed.
>     IFLA_BRIDGE_CFM_CC_CCM_TX:
>         This indicate that the CC transmitted CCM PDU must be configured.
>     IFLA_BRIDGE_CFM_CC_RDI:
>         This indicate that the CC transmitted CCM PDU RDI must be
>         configured.
> 
> 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.
> 
>     Request filter RTEXT_FILTER_CFM_STATUS:
>     Indicating that CFM status information must be delivered.
> 
>     IFLA_BRIDGE_CFM:
>         Points to the CFM information.
> 
>     IFLA_BRIDGE_CFM_MEP_STATUS_INFO:
>         This indicate that the MEP instance status are following.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO:
>         This indicate that the peer MEP status are following.
> 
> CFM nested attribute has the following attributes in next level.
> 
> SETLINK and 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.
> 
> GETLINK RTEXT_FILTER_CFM_STATUS:
>     IFLA_BRIDGE_CFM_MEP_STATUS_INSTANCE:
>         The MEP instance number of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_MEP_STATUS_OPCODE_UNEXP_SEEN:
>         The MEP instance received CFM PDU with unexpected Opcode.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_MEP_STATUS_VERSION_UNEXP_SEEN:
>         The MEP instance received CFM PDU with unexpected version.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_MEP_STATUS_RX_LEVEL_LOW_SEEN:
>         The MEP instance received CCM PDU with MD level lower than
>         configured level. This frame is discarded.
>         The type is u32 (bool).
> 
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_INSTANCE:
>         The MEP instance number of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_PEER_MEPID:
>         The added Peer MEP ID of the delivered status.
>         The type is u32.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_CCM_DEFECT:
>         The CCM defect status.
>         The type is u32 (bool).
>         True means no CCM frame is received for 3.25 intervals.
>         IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_RDI:
>         The last received CCM PDU RDI.
>         The type is u32 (bool).
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_PORT_TLV_VALUE:
>         The last received CCM PDU Port Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_IF_TLV_VALUE:
>         The last received CCM PDU Interface Status TLV value field.
>         The type is u8.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEEN:
>         A CCM frame has been received from Peer MEP.
>         The type is u32 (bool).
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_TLV_SEEN:
>         A CCM frame with TLV has been received from Peer MEP.
>         The type is u32 (bool).
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
>     IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEQ_UNEXP_SEEN:
>         A CCM frame with unexpected sequence number has been received
>         from Peer MEP.
>         The type is u32 (bool).
>         When a sequence number is not one higher than previously received
>         then it is unexpected.
>         This is cleared after GETLINK IFLA_BRIDGE_CFM_CC_PEER_STATUS_INFO.
> 
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> ---
>  include/uapi/linux/if_bridge.h | 125 ++++++
>  include/uapi/linux/rtnetlink.h |   2 +
>  net/bridge/Makefile            |   2 +-
>  net/bridge/br_cfm.c            |   5 +
>  net/bridge/br_cfm_netlink.c    | 724 +++++++++++++++++++++++++++++++++
>  net/bridge/br_netlink.c        |  67 ++-
>  net/bridge/br_private.h        |  31 ++
>  7 files changed, 940 insertions(+), 16 deletions(-)
>  create mode 100644 net/bridge/br_cfm_netlink.c
> 

Hi Henrik,
This patch definitely can be broken into a few smaller ones that add support for
configuring/dumping different cfm parts.

Also, and more importantly, the IFLA_AF_SPEC fix must go to -net as a separate
patch since the problem is there even now. After it gets accepted and -net is
merged into net-next you can rebase on top of it.

Thanks,
 Nik



  reply	other threads:[~2020-10-06 14:46 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 10:30 [net-next v2 00/11] net: bridge: cfm: Add support for Connectivity Fault Management(CFM) Henrik Bjoernlund
2020-10-01 10:30 ` [Bridge] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 01/11] net: bridge: extend the process of special frames Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 16:31   ` kernel test robot
2020-10-01 16:31     ` kernel test robot
2020-10-01 18:02   ` kernel test robot
2020-10-01 18:02     ` kernel test robot
2020-10-01 18:36   ` kernel test robot
2020-10-01 18:36     ` kernel test robot
2020-10-06 14:13   ` Nikolay Aleksandrov
2020-10-06 14:13     ` [Bridge] " Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 02/11] bridge: cfm: Add BRIDGE_CFM to Kconfig Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 03/11] bridge: uapi: cfm: Added EtherType used by the CFM protocol Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 04/11] bridge: cfm: Kernel space implementation of CFM Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-06 14:29   ` Nikolay Aleksandrov
2020-10-06 14:29     ` [Bridge] " Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 05/11] " Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 06/11] " Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 10:30 ` [net-next v2 07/11] bridge: cfm: Netlink Interface Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-06 14:44   ` Nikolay Aleksandrov [this message]
2020-10-06 14:44     ` Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 08/11] bridge: cfm: Netlink Notifications Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-06 14:49   ` Nikolay Aleksandrov
2020-10-06 14:49     ` [Bridge] " Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 09/11] bridge: cfm: Bridge port remove Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-06 14:53   ` Nikolay Aleksandrov
2020-10-06 14:53     ` [Bridge] " Nikolay Aleksandrov
2020-10-01 10:30 ` [net-next v2 10/11] bridge: switchdev: cfm: switchdev interface implementation Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund
2020-10-01 12:49   ` Jiri Pirko
2020-10-05 13:07     ` Allan W. Nielsen
2020-10-05 13:07       ` [Bridge] " Allan W. Nielsen
2020-10-06  9:02       ` Jiri Pirko
2020-10-06 10:50       ` Nikolay Aleksandrov
2020-10-06 10:50         ` [Bridge] " Nikolay Aleksandrov
2020-10-06 10:53         ` allan.nielsen
2020-10-06 10:53           ` [Bridge] " allan.nielsen
2020-10-01 15:20   ` kernel test robot
2020-10-01 15:20     ` kernel test robot
2020-10-01 15:38   ` kernel test robot
2020-10-01 15:38     ` kernel test robot
2020-10-01 10:30 ` [net-next v2 11/11] bridge: cfm: Added CFM switchdev utilization Henrik Bjoernlund
2020-10-01 10:30   ` [Bridge] " Henrik Bjoernlund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=056628d19fcd58c88e084d14ca063204b006f8a4.camel@nvidia.com \
    --to=nikolay@nvidia.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=henrik.bjoernlund@microchip.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=idosch@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.