Re: [PATCH RFC 1/7] net: bridge: extend the process of special frames
Thanks for your review. I will update in the next version as suggested.
Regards
Henrik
The 09/08/2020 12:12, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Fri, 2020-09-04 at 09:15 +, 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
> > ---
> > net/bridge/br_device.c | 1 +
> > net/bridge/br_input.c | 31 ++-
> > net/bridge/br_mrp.c | 19 +++
> > net/bridge/br_private.h | 18 --
> > 4 files changed, 58 insertions(+), 11 deletions(-)
> >
>
> Hi,
> First I must say I do like this approach, thanks for generalizing it.
> You can switch to a hlist so that there's just 1 pointer in the head.
> I don't think you need list when you're walking only in one direction.
> A few more minor comments below.
>
> > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> > index 9a2fb4aa1a10..a9232db03108 100644
> > --- a/net/bridge/br_device.c
> > +++ b/net/bridge/br_device.c
> > @@ -473,6 +473,7 @@ void br_dev_setup(struct net_device *dev)
> > spin_lock_init(&br->lock);
> > INIT_LIST_HEAD(&br->port_list);
> > INIT_HLIST_HEAD(&br->fdb_list);
> > + INIT_LIST_HEAD(&br->ftype_list);
> > #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> > INIT_LIST_HEAD(&br->mrp_list);
> > #endif
> > diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> > index 59a318b9f646..0f475b21094c 100644
> > --- a/net/bridge/br_input.c
> > +++ b/net/bridge/br_input.c
> > @@ -254,6 +254,21 @@ static int nf_hook_bridge_pre(struct sk_buff *skb,
> > struct sk_buff **pskb)
> > return RX_HANDLER_CONSUMED;
> > }
> >
> > +/* Return 0 if the frame was not processed otherwise 1
> > + * note: already called with rcu_read_lock
> > + */
> > +static int br_process_frame_type(struct net_bridge_port *p,
> > + struct sk_buff *skb)
> > +{
> > + struct br_frame_type *tmp;
> > +
> > + list_for_each_entry_rcu(tmp, &p->br->ftype_list, list) {
> > + if (unlikely(tmp->type == skb->protocol))
> > + return tmp->func(p, skb);
> > + }
>
> Nit: you can drop the {}.
>
> > + return 0;
> > +}
> > +
> > /*
> > * Return NULL if skb is handled
> > * note: already called with rcu_read_lock
> > @@ -343,7 +358,7 @@ static rx_handler_result_t br_handle_frame(struct
> > sk_buff **pskb)
> > }
> > }
> >
> > - if (unlikely(br_mrp_process(p, skb)))
> > + if (unlikely(br_process_frame_type(p, skb)))
> > return RX_HANDLER_PASS;
> >
> > forward:
> > @@ -380,3 +395,17 @@ rx_handler_func_t *br_get_rx_handler(const struct
> > net_device *dev)
> >
> > return br_handle_frame;
> > }
> > +
> > +void br_add_frame(struct net_bridge *br, struct br_frame_type *ft)
> > +{
> > + list_add_rcu(&ft->list, &br->ftype_list);
> > +}
> > +
> > +void br_del_frame(struct net_bridge *br, struct br_frame_type *ft)
> > +{
> > + struct br_frame_type *tmp;
> > +
> > + list_for_each_entry(tmp, &br->ftype_list, list)
> > + if (ft == tmp)
> > + list_del_rcu(&ft->list);
> > +}
> > diff --git a/net/bridge/br_mrp.c b/net/bridge/br_mrp.c
> > index b36689e6e7cb..0428e1785041 100644
> > --- a/net/bridge/br_mrp.c
> > +++ b/net/bridge/br_mrp.c
> > @@ -6,6 +6,13 @@
> > static const u8 mrp_test_dmac[ETH_ALEN] = { 0x1, 0x15, 0x4e, 0x0, 0x0, 0x1
> > };
> > static const u8 mrp_in_test_dmac[ETH_ALEN] = { 0x1, 0x15, 0x4e, 0x0, 0x0,
> > 0x3 };
> >
> > +static int br_mrp_process(struct net_bridge_port *p, struct sk_buff *skb);
> > +
> > +static struct br_frame_type mrp_frame_type __read_mostly = {
> > + .type = cpu_to_be16(ETH_P_MRP),
> > + .func = br_mrp_process,
> > +};
> > +
> > static bool br_mrp_is_ring_port(struct net_bridge_port *p_port,
> > struct net_bridge_port *s_port,
> > struct net_bridge_port *port)
> > @@ -445,6 +452,9 @@ static void br_mrp_del_impl(struct net_bridge *br,
> > struct br_mrp *mrp)
> >
> > list_del_rcu(&mrp->list);
> > kfree_rcu(mrp, rcu);
> > +
> > + if (list_empty(&br->mrp_list))
> > + br_del_frame(br, &mrp_frame_type);
> > }
> >
> > /* Adds a new MRP instance.
> > @@ -493,6 +503,9 @@ int br_mrp_add(struct n
Re: [PATCH RFC 2/7] bridge: cfm: Add BRIDGE_CFM to Kconfig.
Thanks for your review. I will update in the next version as suggested.
Regards
Henrik
The 09/08/2020 12:18, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Fri, 2020-09-04 at 09:15 +, Henrik Bjoernlund wrote:
> > This makes it possible to include or exclude the CFM
> > protocol according to 802.1Q section 12.14.
> >
> > Signed-off-by: Henrik Bjoernlund
> > ---
> > net/bridge/Kconfig | 11 +++
> > net/bridge/br_device.c | 3 +++
> > net/bridge/br_private.h | 3 +++
> > 3 files changed, 17 insertions(+)
> >
> > diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
> > index 80879196560c..3c8ded7d3e84 100644
> > --- a/net/bridge/Kconfig
> > +++ b/net/bridge/Kconfig
> > @@ -73,3 +73,14 @@ config BRIDGE_MRP
> > Say N to exclude this support and reduce the binary size.
> >
> > If unsure, say N.
> > +
> > +config BRIDGE_CFM
> > + bool "CFM protocol"
> > + depends on BRIDGE
> > + help
> > + If you say Y here, then the Ethernet bridge will be able to run CFM
> > + protocol according to 802.1Q section 12.14
> > +
> > + Say N to exclude this support and reduce the binary size.
> > +
> > + If unsure, say N.
> > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> > index a9232db03108..d12f5626a4b1 100644
> > --- a/net/bridge/br_device.c
> > +++ b/net/bridge/br_device.c
> > @@ -476,6 +476,9 @@ void br_dev_setup(struct net_device *dev)
> > INIT_LIST_HEAD(&br->ftype_list);
> > #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> > INIT_LIST_HEAD(&br->mrp_list);
> > +#endif
> > +#if IS_ENABLED(CONFIG_BRIDGE_CFM)
> > + INIT_LIST_HEAD(&br->mep_list);
> > #endif
> > spin_lock_init(&br->hash_lock);
> >
> > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> > index e67c6d9e8bea..6294a3e51a33 100644
> > --- a/net/bridge/br_private.h
> > +++ b/net/bridge/br_private.h
> > @@ -445,6 +445,9 @@ struct net_bridge {
> > #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> > struct list_headmrp_list;
> > #endif
> > +#if IS_ENABLED(CONFIG_BRIDGE_CFM)
> > + struct list_headmep_list;
> > +#endif
> > };
> >
> > struct br_input_skb_cb {
>
> Looks good, perhaps also can use hlist to reduce the head size in net_bridge.
>
--
/Henrik
Re: [PATCH RFC 4/7] bridge: cfm: Kernel space implementation of CFM.
Thanks for the review. Comments below. The 09/08/2020 13:16, Nikolay Aleksandrov wrote: > > On Fri, 2020-09-04 at 09:15 +, Henrik Bjoernlund wrote: > > This is the implementation of the CFM protocol according to > > 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 > > > > Interface consists of these functions: > > br_cfm_mep_create() > > br_cfm_mep_delete() > > br_cfm_mep_config_set() > > br_cfm_mep_status_get() > > br_cfm_mep_counters_get() > > br_cfm_mep_counters_clear() > > br_cfm_cc_config_set() > > br_cfm_cc_peer_mep_add() > > br_cfm_cc_peer_mep_remove() > > br_cfm_cc_rdi_set() > > br_cfm_cc_ccm_tx() > > br_cfm_cc_status_get() > > br_cfm_cc_counters_get() > > br_cfm_cc_counters_clear() > > br_cfm_cc_peer_status_get() > > > > A MEP instance is created by br_cfm_mep_create() > > -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 validates CFM frames on its level. > > -It can only exist on a port that is related to a bridge. > > -Attributes given cannot be changed until the instance is > > deleted. > > > > A MEP instance can be deleted by br_cfm_mep_delete(). > > > > A created MEP instance has attributes that can be > > configured by br_cfm_mep_config_set(). > > > > A MEP contain status and counter information that can be > > retrieved by br_cfm_mep_status_get() and > > br_cfm_mep_counters_get(). > > > > A MEP counters can be cleared by br_cfm_mep_counters_clear(). > > > > A MEP Continuity Check feature can be configured by > > br_cfm_cc_config_set() > > The Continuity Check Receiver state machine can be > > enabled and disabled. > > According to 802.1Q section 19.2.8 > > > > A MEP can have Peer MEPs added and removed by > > br_cfm_cc_peer_mep_add() and br_cfm_cc_peer_mep_remove() > > The Continuity Check feature can maintain connectivity > > status on each added Peer MEP. > > > > A MEP can be configured to start or stop transmission of CCM frames by > > br_cfm_cc_ccm_tx() > > The CCM will be transmitted for a selected period in seconds. > > Must call this function before timeout to keep transmission alive. > > > > A MEP transmitting CCM can be configured with inserted RDI in PDU by > > br_cfm_cc_rdi_set() > > > > A MEP contain Continuity Check status and counter information > > that can be retrieved by br_cfm_cc_status_get() and > > br_cfm_cc_counters_get(). > > > > A MEP Continuity Check counters can be cleared > > by br_cfm_cc_counters_clear(). > > > > A MEP contain Peer MEP Continuity Check status information that > > can be retrieved by br_cfm_cc_peer_status_get(). > > > > Signed-off-by: Henrik Bjoernlund > > --- > > include/uapi/linux/cfm_bridge.h | 75 +++ > > net/bridge/Makefile | 2 + > > net/bridge/br_cfm.c | 880 > > net/bridge/br_private.h | 16 + > > net/bridge/br_private_cfm.h | 242 + > > 5 files changed, 1215 insertions(+) > > create mode 100644 include/uapi/linux/cfm_bridge.h > > create mode 100644 net/bridge/br_cfm.c > > create mode 100644 net/bridge/br_private_cfm.h > > > > This is a large single patch, do you think it can be broken down into pieces? > I'll review it like this now, but it would be much easier if it's in smaller > logical pieces. > In general are you sure there are no holes in the structs being assigned > directly? Since you use memcmp() and such, you could end up surprised. :) > I will try and break this patch up into logical pieces. I will assure that when called from br_cfm_netlink.c the struct is memset to zero before members are set. > > diff --git a/include/uapi/linux/cfm_bridge.h > > b/include/uapi/linux/cfm_bridge.h > > new file mode 100644 > > index ..389ea1e1f68e > > --- /dev/null > > +++ b/include/uapi/linux/cfm_bridge.h > > @@ -0,0 +1,75 @@ > > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ > > + > > +#ifndef _UAPI_LINUX_CFM_BRIDGE_H_ > > +#define _UAPI_LINUX_CFM_BRIDGE_H_ > > + > > +#include > > +#include > > + > > +#define ETHER_HEADER_LENGTH (6+6+4+2) > > +#define CFM_MAID_LENGTH 48 > > +#define CFM_CCM_PDU_LENGTH 75 > > +#define CFM_PORT_STATUS_TLV_LENGTH 4 > > +#define CFM_IF_STATUS_TLV_LENGTH 4 > > +#define CFM_IF_STATUS_TLV_TYPE 4
Re: [PATCH RFC 5/7] bridge: cfm: Netlink Interface.
Thanks for the review. Comments below.
The 09/08/2020 13:47, Nikolay Aleksandrov wrote:
>
> On Fri, 2020-09-04 at 09:15 +, 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.
> [snip]
> > __u64 transition_fwd;
> > diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
> > index 9b814c92de12..fdd408f6a5d2 100644
> > --- a/include/uapi/linux/rtnetlink.h
> > +++ b/include/uapi/linux/rtnetlink.h
> > @@ -779,6 +779,8 @@ enum {
> > #define RTEXT_FILTER_BRVLAN_COMPRESSED (1 << 2)
> > #define RTEXT_FILTER_SKIP_STATS (1 << 3)
> > #define RTEXT_FILTER_MRP (1 << 4)
> > +#define RTEXT_FILTER_CFM_CONFIG (1 << 5)
> > +#define RTEXT_FILTER_CFM_STATUS (1 << 6)
> >
> > /* End of information exported to user level */
> >
> > diff --git a/net/bridge/Makefile b/net/bridge/Makefile
> > index ddc0a9192348..4702702a74d3 100644
> > --- a/net/bridge/Makefile
> > +++ b/net/bridge/Makefile
> > @@ -28,4 +28,4 @@ obj-$(CONFIG_NETFILTER) += netfilter/
> >
> > bridge-$(CONFIG_BRIDGE_MRP) += br_mrp_switchdev.o br_mrp.o
> > br_mrp_netlink.o
> >
> > -bridge-$(CONFIG_BRIDGE_CFM) += br_cfm.o
> > +bridge-$(CONFIG_BRIDGE_CFM) += br_cfm.o br_cfm_netlink.o
> > diff --git a/net/bridge/br_cfm_netlink.c b/net/bridge/br_cfm_netlink.c
> > new file mode 100644
> > index ..4e39aab1cd0b
> > --- /dev/null
> > +++ b/net/bridge/br_cfm_netlink.c
> > @@ -0,0 +1,684 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +#include
> > +
> > +#include "br_private.h"
> > +#include "br_private_cfm.h"
> > +
> > +static inline struct mac_addr nla_get_mac(const struct nlattr *nla)
> > +{
> > + struct mac_addr mac;
> > +
> > + nla_memcpy(&mac.addr, nla, sizeof(mac.addr));
> > +
> > + return mac;
> > +}
> > +
> > +static inline struct br_cfm_maid nla_get_maid(const struct nlattr *nla)
> > +{
> > + struct br_cfm_maid maid;
> > +
> > + nla_memcpy(&maid.data, nla, sizeof(maid.data));
> > +
> > + return maid;
> > +}
>
> IMO, these 1-line helpers don't really help readability.
>
I think they make a difference - you can write nicely in one line:
config.unicast_mac = nla_get_mac(tb[IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC]);
Also you can argue the same with functions nla_get_u32() and nla_get_u8 () they
are one liner functions.
I you think it must be changed I will ofc do it.
> > +
> > +static inline int nla_put_u64(struct sk_buff *skb, int attrtype, u64 value)
> > +{
> > + u64 tmp = value;
> > +
> > + return nla_put(skb, attrtype, sizeof(u64), &tmp);
> > +}
>
> What?! Read include/net/netlink.h
>
I have removed this. Not used anyway.
> > +
> > +static const struct nla_policy
> > +br_cfm_policy[IFLA_BRIDGE_CFM_MAX + 1] = {
> > + [IFLA_BRIDGE_CFM_UNSPEC]= { .type = NLA_REJECT },
> > + [IFLA_BRIDGE_CFM_MEP_CREATE]= { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_MEP_DELETE]= { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG]= { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_CC_CONFIG] = { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD] = { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE]= { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_CC_RDI]= { .type = NLA_NESTED },
> > + [IFLA_BRIDGE_CFM_CC_CCM_TX] = { .type = NLA_NESTED },
> > +};
> > +
> > +static const struct nla_policy
> > +br_cfm_mep_create_policy[IFLA_BRIDGE_CFM_MEP_CREATE_MAX + 1] = {
> > + [IFLA_BRIDGE_CFM_MEP_CREATE_UNSPEC] = { .type = NLA_REJECT },
> > + [IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX]= { .type = NLA_U32 },
> > +};
> > +
> > +static const struct nla_policy
> > +br_cfm_mep_delete_policy[IFLA_BRIDGE_CFM_MEP_DELETE_MAX + 1] = {
> > + [IFLA_BRIDGE_CFM_MEP_DELETE_UNSPEC] = { .type = NLA_REJECT },
> > + [IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE] = { .type = NLA_U32 },
> > +};
> > +
> > +static const struct nla_policy
> > +br_cfm_mep_config_policy[IFLA_BRIDGE_CFM_MEP_CONFIG_MAX + 1] = {
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG_UNSPEC] = { .type =
> > NLA_REJECT },
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC]= NLA_POLICY_ETH_ADDR,
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL]= { .type = NLA_U32 },
> > + [IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID] =
Re: [PATCH RFC 6/7] bridge: cfm: Netlink Notifications.
Thanks for the review. Comments below.
The 09/08/2020 13:54, Nikolay Aleksandrov wrote:
>
> On Fri, 2020-09-04 at 09:15 +, Henrik Bjoernlund wrote:
> > This is the implementation of Netlink notifications out of CFM.
> >
> > Notifications are initiated whenever a state change happens in CFM.
> >
> [snip]
> > @@ -445,6 +458,7 @@ static int br_cfm_frame_rx(struct net_bridge_port
> > *port, struct sk_buff *skb)
> > peer_mep->cc_status.ccm_defect = false;
> >
> > /* Change in CCM defect status - notify */
> > + br_cfm_notify(RTM_NEWLINK, port);
> >
> > /* Start CCM RX timer */
> > ccm_rx_timer_start(peer_mep);
> > @@ -874,6 +888,35 @@ int br_cfm_cc_counters_clear(struct net_bridge *br,
> > const u32 instance,
> > return 0;
> > }
> >
> > +int br_cfm_mep_count(struct net_bridge *br, u32 *count)
> > +{
> > + struct br_cfm_mep *mep;
>
> Leave a blank line between local variable definitions and code.
>
I will change that as suggested.
> > + *count = 0;
> > +
> > + rcu_read_lock();
> > + list_for_each_entry_rcu(mep, &br->mep_list, head)
> > + * count += 1;
>
> please remove the extra space
>
I will change that as suggested.
> > + rcu_read_unlock();
> > +
> > + return 0;
> > +}
> > +
> > +int br_cfm_peer_mep_count(struct net_bridge *br, u32 *count)
> > +{
> > + struct br_cfm_peer_mep *peer_mep;
> > + struct br_cfm_mep *mep;
>
> Leave a blank line between local variable definitions and code.
>
I will change that as suggested.
> > + *count = 0;
> > +
> > + rcu_read_lock();
> > + list_for_each_entry_rcu(mep, &br->mep_list, head) {
> > + list_for_each_entry_rcu(peer_mep, &mep->peer_mep_list, head)
> > + * count += 1;
>
> please remove the extra space
>
I will change that as suggested.
> > + }
> > + rcu_read_unlock();
> > +
> > + return 0;
> > +}
> > +
> > bool br_cfm_created(struct net_bridge *br)
> > {
> > return !list_empty(&br->mep_list);
> > diff --git a/net/bridge/br_cfm_netlink.c b/net/bridge/br_cfm_netlink.c
> > index 4e39aab1cd0b..13664ac8608a 100644
> > --- a/net/bridge/br_cfm_netlink.c
> > +++ b/net/bridge/br_cfm_netlink.c
> > @@ -582,7 +582,9 @@ int br_cfm_config_fill_info(struct sk_buff *skb, struct
> > net_bridge *br)
> > return -EMSGSIZE;
> > }
> >
> > -int br_cfm_status_fill_info(struct sk_buff *skb, struct net_bridge *br)
> > +int br_cfm_status_fill_info(struct sk_buff *skb,
> > + struct net_bridge *br,
> > + bool getlink)
> > {
> > struct nlattr *tb, *cfm_tb;
> > struct br_cfm_mep *mep;
> > @@ -613,10 +615,12 @@ int br_cfm_status_fill_info(struct sk_buff *skb,
> > struct net_bridge *br)
> > mep->status.rx_level_low_seen))
> > goto nla_put_failure;
> >
> > - /* Clear all 'seen' indications */
> > - mep->status.opcode_unexp_seen = false;
> > - mep->status.version_unexp_seen = false;
> > - mep->status.rx_level_low_seen = false;
> > + if (getlink) { /* Only clear if this is a GETLINK */
> > + /* Clear all 'seen' indications */
> > + mep->status.opcode_unexp_seen = false;
> > + mep->status.version_unexp_seen = false;
> > + mep->status.rx_level_low_seen = false;
> > + }
> >
> > nla_nest_end(skb, tb);
> >
> > @@ -662,10 +666,12 @@ int br_cfm_status_fill_info(struct sk_buff *skb,
> > struct net_bridge *br)
> > peer_mep->cc_status.seq_unexp_seen))
> > goto nla_put_failure;
> >
> > - /* Clear all 'seen' indications */
> > - peer_mep->cc_status.seen = false;
> > - peer_mep->cc_status.tlv_seen = false;
> > - peer_mep->cc_status.seq_unexp_seen = false;
> > + if (getlink) { /* Only clear if this is a GETLINK */
> > + /* Clear all 'seen' indications */
> > + peer_mep->cc_status.seen = false;
> > + peer_mep->cc_status.tlv_seen = false;
> > + peer_mep->cc_status.seq_unexp_seen = false;
>
> Why clear these on GETLINK? This sounds like it should be a set op.
>
The idea is that when getting the CFM status any '_seen' indications are
cleared so that they are giving information about what was seen since
last get.
I assume this is a get/clear atomic operations as rcu is held.
If you think this must be changed to a seperate clear_set operation I
will ofc do it.
> > + }
> >
> > nla_nest_end(skb, tb);
> > }
> > diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> >
Re: [PATCH RFC 7/7] bridge: cfm: Bridge port remove.
Thanks for the review. I will update the next version as suggested.
The 09/08/2020 13:58, Nikolay Aleksandrov wrote:
>
> On Fri, 2020-09-04 at 09:15 +, Henrik Bjoernlund wrote:
> > This is addition of CFM functionality to delete MEP instances
> > on a port that is removed from the bridge.
> > A MEP can only exist on a port that is related to a bridge.
> >
> > Signed-off-by: Henrik Bjoernlund
> > ---
> > net/bridge/br_cfm.c | 13 +
> > net/bridge/br_if.c | 1 +
> > net/bridge/br_private.h | 6 ++
> > 3 files changed, 20 insertions(+)
> >
> > diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
> > index b7fed2c1d8ec..c724ce020ce3 100644
> > --- a/net/bridge/br_cfm.c
> > +++ b/net/bridge/br_cfm.c
> > @@ -921,3 +921,16 @@ bool br_cfm_created(struct net_bridge *br)
> > {
> > return !list_empty(&br->mep_list);
> > }
> > +
> > +/* Deletes the CFM instances on a specific bridge port
> > + * note: called under rtnl_lock
> > + */
> > +void br_cfm_port_del(struct net_bridge *br, struct net_bridge_port *port)
> > +{
> > + struct br_cfm_mep *mep;
> > +
> > + list_for_each_entry_rcu(mep, &br->mep_list, head,
> > + lockdep_rtnl_is_held())
>
> Use standard/non-rcu list traversing, rtnl is already held.
>
> > + if (mep->create.ifindex == port->dev->ifindex)
> > + mep_delete_implementation(br, mep);
> > +}
> > diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> > index a0e9a7937412..f7d2f472ae24 100644
> > --- a/net/bridge/br_if.c
> > +++ b/net/bridge/br_if.c
> > @@ -334,6 +334,7 @@ static void del_nbp(struct net_bridge_port *p)
> > spin_unlock_bh(&br->lock);
> >
> > br_mrp_port_del(br, p);
> > + br_cfm_port_del(br, p);
> >
> > br_ifinfo_notify(RTM_DELLINK, NULL, p);
> >
> > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> > index 53bcbdd21f34..5617255f0c0c 100644
> > --- a/net/bridge/br_private.h
> > +++ b/net/bridge/br_private.h
> > @@ -1369,6 +1369,7 @@ int br_cfm_parse(struct net_bridge *br, struct
> > net_bridge_port *p,
> >struct nlattr *attr, int cmd, struct netlink_ext_ack
> > *extack);
> > int br_cfm_rx_frame_process(struct net_bridge_port *p, struct sk_buff
> > *skb);
> > bool br_cfm_created(struct net_bridge *br);
> > +void br_cfm_port_del(struct net_bridge *br, struct net_bridge_port *p);
> > int br_cfm_config_fill_info(struct sk_buff *skb, struct net_bridge *br);
> > int br_cfm_status_fill_info(struct sk_buff *skb,
> > struct net_bridge *br,
> > @@ -1393,6 +1394,11 @@ static inline bool br_cfm_created(struct net_bridge
> > *br)
> > return false;
> > }
> >
> > +static inline void br_cfm_port_del(struct net_bridge *br,
> > +struct net_bridge_port *p)
> > +{
> > +}
> > +
> > static inline int br_cfm_config_fill_info(struct sk_buff *skb, struct
> > net_bridge *br)
> > {
> > return -EOPNOTSUPP;
>
--
/Henrik
Re: [PATCH RFC 6/7] bridge: cfm: Netlink Notifications.
Thanks for the review. Comments below. The 09/08/2020 13:54, Nikolay Aleksandrov wrote: > > On Fri, 2020-09-04 at 09:15 +, Henrik Bjoernlund wrote: > > This is the implementation of Netlink notifications out of CFM. > > > > Notifications are initiated whenever a state change happens in CFM. > > > [snip] > > + *count = 0; > > + > > + rcu_read_lock(); > > + list_for_each_entry_rcu(mep, &br->mep_list, head) > > + * count += 1; > > please remove the extra space > I have removed the extra space. This space was added to satify checkpatch as without this space it gives this error: CHECK: spaces preferred around that '*' (ctx:ExV) #136: FILE: net/bridge/br_cfm.c:883: + *count += 1; ^ > > + rcu_read_unlock(); > > + > > + return 0; > > +} > > + > > -- /Henrik
Re: [PATCH net-next v4 01/10] net: bridge: extend the process of special frames
Thanks for the review. Comments below.
The 10/12/2020 09:12, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Fri, 2020-10-09 at 14:35 +, 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
> > Reviewed-by: Horatiu Vultur
> > ---
> > net/bridge/br_device.c | 1 +
> > net/bridge/br_input.c | 33 -
> > net/bridge/br_mrp.c | 19 +++
> > net/bridge/br_private.h | 18 --
> > 4 files changed, 60 insertions(+), 11 deletions(-)
> >
> [snip]
> > diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> > index 345118e35c42..3e62ce2ef8a5 100644
> > --- a/net/bridge/br_private.h
> > +++ b/net/bridge/br_private.h
> > @@ -480,6 +480,8 @@ struct net_bridge {
> > #endif
> > struct hlist_head fdb_list;
> >
> > + struct hlist_head frame_type_list;
>
> Since there will be a v5, I'd suggest to move this struct member in the first
> cache line as it will be always used in the bridge fast-path for all cases.
> In order to make room for it there you can move port_list after fdb_hash_tbl
> and
> add this in its place, port_list is currently used only when flooding and soon
> I'll even change that.
>
> Thanks,
> Nik
>
I will do change as requested.
> > +
> > #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> > struct list_headmrp_list;
> > #endif
> > @@ -755,6 +757,16 @@ int nbp_backup_change(struct net_bridge_port *p,
> > struct net_device *backup_dev);
> > int br_handle_frame_finish(struct net *net, struct sock *sk, struct
> > sk_buff *skb);
> > rx_handler_func_t *br_get_rx_handler(const struct net_device *dev);
> >
> > +struct br_frame_type {
> > + __be16 type;
> > + int (*frame_handler)(struct net_bridge_port *port,
> > + struct sk_buff *skb);
> > + struct hlist_node list;
> > +};
> > +
> > +void br_add_frame(struct net_bridge *br, struct br_frame_type *ft);
> > +void br_del_frame(struct net_bridge *br, struct br_frame_type *ft);
> > +
> > static inline bool br_rx_handler_check_rcu(const struct net_device *dev)
> > {
> > return rcu_dereference(dev->rx_handler) == br_get_rx_handler(dev);
> > @@ -1417,7 +1429,6 @@ extern int (*br_fdb_test_addr_hook)(struct net_device
> > *dev, unsigned char *addr)
> > #if IS_ENABLED(CONFIG_BRIDGE_MRP)
> > int br_mrp_parse(struct net_bridge *br, struct net_bridge_port *p,
> >struct nlattr *attr, int cmd, struct netlink_ext_ack
> > *extack);
> > -int br_mrp_process(struct net_bridge_port *p, struct sk_buff *skb);
> > bool br_mrp_enabled(struct net_bridge *br);
> > void br_mrp_port_del(struct net_bridge *br, struct net_bridge_port *p);
> > int br_mrp_fill_info(struct sk_buff *skb, struct net_bridge *br);
> > @@ -1429,11 +1440,6 @@ static inline int br_mrp_parse(struct net_bridge
> > *br, struct net_bridge_port *p,
> > return -EOPNOTSUPP;
> > }
> >
> > -static inline int br_mrp_process(struct net_bridge_port *p, struct sk_buff
> > *skb)
> > -{
> > - return 0;
> > -}
> > -
> > static inline bool br_mrp_enabled(struct net_bridge *br)
> > {
> > return false;
>
--
/Henrik
Re: [PATCH net-next v4 07/10] bridge: cfm: Netlink SET configuration Interface.
The 10/09/2020 21:53, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This is the implementation of CFM netlink configuration > > set information interface. > > > > Add new nested netlink attributes. These attributes are used by the > > user space to create/delete/configure CFM instances. > > > > 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. > > > > CFM nested attribute has the following attributes in next level. > > > > SETLINK 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
Re: [PATCH net-next v4 10/10] bridge: cfm: Netlink Notifications.
The 10/09/2020 22:03, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This is the implementation of Netlink notifications out of CFM. > > > > Notifications are initiated whenever a state change happens in CFM. > > > > 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. > > > > IFLA_BRIDGE_CFM_MEP_STATUS_INSTANCE: > > The MEP instance number of the delivered status. > > The type is NLA_U32. > > IFLA_BRIDGE_CFM_MEP_STATUS_OPCODE_UNEXP_SEEN: > > The MEP instance received CFM PDU with unexpected Opcode. > > The type is NLA_U32 (bool). > > IFLA_BRIDGE_CFM_MEP_STATUS_VERSION_UNEXP_SEEN: > > The MEP instance received CFM PDU with unexpected version. > > The type is NLA_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 NLA_U32 (bool). > > > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_INSTANCE: > > The MEP instance number of the delivered status. > > The type is NLA_U32. > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_PEER_MEPID: > > The added Peer MEP ID of the delivered status. > > The type is NLA_U32. > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_CCM_DEFECT: > > The CCM defect status. > > The type is NLA_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 NLA_U32 (bool). > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_PORT_TLV_VALUE: > > The last received CCM PDU Port Status TLV value field. > > The type is NLA_U8. > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_IF_TLV_VALUE: > > The last received CCM PDU Interface Status TLV value field. > > The type is NLA_U8. > > IFLA_BRIDGE_CFM_CC_PEER_STATUS_SEEN: > > A CCM frame has been received from Peer MEP. > > The type is NLA_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 NLA_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 NLA_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. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > net/bridge/br_cfm.c | 48 > > net/bridge/br_cfm_netlink.c | 25 - > > net/bridge/br_netlink.c | 73 - > > net/bridge/br_private.h | 22 ++- > > 4 files changed, 147 insertions(+), 21 deletions(-) > > > > Acked-by: Nikolay Aleksandrov > Thanks for the review. -- /Henrik
Re: [PATCH net-next v4 08/10] bridge: cfm: Netlink GET configuration Interface.
Thanks for the review. Comments below. The 10/09/2020 21:59, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Sat, 2020-10-10 at 00:56 +0300, Nikolay Aleksandrov wrote: > > On Fri, 2020-10-09 at 14:35 +, 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 instanc
Re: [PATCH net-next v4 09/10] bridge: cfm: Netlink GET status Interface.
Thanks for the review. Comments below.
The 10/09/2020 22:00, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote:
> > This is the implementation of CFM netlink status
> > get information interface.
> >
> > Add new nested netlink attributes. These attributes are used by the
> > user space to get status information.
> >
> > GETLINK:
> > 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.
> >
> > 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.
> >
> > Signed-off-by: Henrik Bjoernlund
> > Reviewed-by: Horatiu Vultur
> > ---
> > include/uapi/linux/if_bridge.h | 29 +
> > include/uapi/linux/rtnetlink.h | 1 +
> > net/bridge/br_cfm_netlink.c| 105 +
> > net/bridge/br_netlink.c| 16 -
> > net/bridge/br_private.h| 6 ++
> > 5 files changed, 154 insertions(+), 3 deletions(-)
> >
> [snip]
> > diff --git a/net/bridge/br_cfm_netlink.c b/net/bridge/br_cfm_netlink.c
> > index 952b6372874e..94e9b46d5fb4 100644
> > --- a/net/bridge/br_cfm_netlink.c
> > +++ b/net/bridge/br_cfm_netlink.c
> > @@ -617,3 +617,108 @@ int br_cfm_config_fill_info(struct sk_buff *skb,
> > struct net_bridge *br)
> > nla_info_failure:
> > return -EMSGSIZE;
> > }
> > +
> > +int br_cfm_status_fill_info(struct sk_buff *skb, struct net_bridge *br)
> > +{
> > + struct nlattr *tb;
> > + struct br_cfm_mep *mep;
> > + struct br_cfm_peer_mep *peer_mep;
> > +
> >
>
> Reverse xmas tree here, too. Sorry I missed these earlier.
>
I chande this as requested.
>
--
/Henrik
Re: [PATCH net-next v4 08/10] bridge: cfm: Netlink GET configuration Interface.
Thanks for the review. The 10/09/2020 21:56, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, 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: >
Re: [PATCH net-next v4 06/10] bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.
Thanks for the review. The 10/09/2020 21:52, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This is the third commit of the implementation of the CFM protocol > > according to 802.1Q section 12.14. > > > > Functionality is extended with CCM frame reception. > > The MEP instance now contains CCM based status information. > > Most important is the CCM defect status indicating if correct > > CCM frames are received with the expected interval. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > include/uapi/linux/cfm_bridge.h | 10 ++ > > net/bridge/br_cfm.c | 269 > > net/bridge/br_private_cfm.h | 32 > > 3 files changed, 311 insertions(+) > > > > Acked-by: Nikolay Aleksandrov > > -- /Henrik
Re: [PATCH net-next v4 05/10] bridge: cfm: Kernel space implementation of CFM. CCM frame TX added.
Thanks for the review. The 10/09/2020 21:49, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This is the second commit of the implementation of the CFM protocol > > according to 802.1Q section 12.14. > > > > Functionality is extended with CCM frame transmission. > > > > Interface is extended with these functions: > > br_cfm_cc_rdi_set() > > br_cfm_cc_ccm_tx() > > br_cfm_cc_config_set() > > > > A MEP Continuity Check feature can be configured by > > br_cfm_cc_config_set() > > The Continuity Check parameters can be configured to be used when > > transmitting CCM. > > > > A MEP can be configured to start or stop transmission of CCM frames by > > br_cfm_cc_ccm_tx() > > The CCM will be transmitted for a selected period in seconds. > > Must call this function before timeout to keep transmission alive. > > > > A MEP transmitting CCM can be configured with inserted RDI in PDU by > > br_cfm_cc_rdi_set() > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > include/uapi/linux/cfm_bridge.h | 39 - > > net/bridge/br_cfm.c | 284 > > net/bridge/br_private_cfm.h | 54 ++ > > 3 files changed, 376 insertions(+), 1 deletion(-) > > > > Acked-by: Nikolay Aleksandrov > -- /Henrik
Re: [PATCH net-next v4 04/10] bridge: cfm: Kernel space implementation of CFM. MEP create/delete.
Thanks for the review. The 10/09/2020 21:42, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This is the first commit of the implementation of the CFM protocol > > according to 802.1Q section 12.14. > > > > It contains MEP instance create, delete and configuration. > > > > 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<80><99>s equipment. > > > > CFM functions are partitioned as follows: > > - Path discovery > > - Fault detection > > - Fault verification and isolation > > - Fault notification > > - Fault recovery > > > > Interface consists of these functions: > > br_cfm_mep_create() > > br_cfm_mep_delete() > > br_cfm_mep_config_set() > > br_cfm_cc_config_set() > > br_cfm_cc_peer_mep_add() > > br_cfm_cc_peer_mep_remove() > > > > A MEP instance is created by br_cfm_mep_create() > > -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 validates CFM frames on its level. > > -It can only exist on a port that is related to a bridge. > > -Attributes given cannot be changed until the instance is > > deleted. > > > > A MEP instance can be deleted by br_cfm_mep_delete(). > > > > A created MEP instance has attributes that can be > > configured by br_cfm_mep_config_set(). > > > > A MEP Continuity Check feature can be configured by > > br_cfm_cc_config_set() > > The Continuity Check Receiver state machine can be > > enabled and disabled. > > According to 802.1Q section 19.2.8 > > > > A MEP can have Peer MEPs added and removed by > > br_cfm_cc_peer_mep_add() and br_cfm_cc_peer_mep_remove() > > The Continuity Check feature can maintain connectivity > > status on each added Peer MEP. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > include/uapi/linux/cfm_bridge.h | 23 +++ > > net/bridge/Makefile | 2 + > > net/bridge/br_cfm.c | 278 > > net/bridge/br_if.c | 1 + > > net/bridge/br_private.h | 10 ++ > > net/bridge/br_private_cfm.h | 61 +++ > > 6 files changed, 375 insertions(+) > > create mode 100644 include/uapi/linux/cfm_bridge.h > > create mode 100644 net/bridge/br_cfm.c > > create mode 100644 net/bridge/br_private_cfm.h > > > > Acked-by: Nikolay Aleksandrov > -- /Henrik
Re: [PATCH net-next v4 03/10] bridge: uapi: cfm: Added EtherType used by the CFM protocol.
Thanks for the review. The 10/09/2020 21:41, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This EtherType is used by all CFM protocal frames transmitted > > according to 802.1Q section 12.14. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > Acked-by: Nikolay Aleksandrov > > --- > > include/uapi/linux/if_ether.h | 1 + > > 1 file changed, 1 insertion(+) > > > > Acked-by: Nikolay Aleksandrov -- /Henrik
Re: [PATCH net-next v4 02/10] bridge: cfm: Add BRIDGE_CFM to Kconfig.
Thanks for the review. The 10/09/2020 21:39, Nikolay Aleksandrov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Fri, 2020-10-09 at 14:35 +, Henrik Bjoernlund wrote: > > This makes it possible to include or exclude the CFM > > protocol according to 802.1Q section 12.14. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > net/bridge/Kconfig | 11 +++ > > net/bridge/br_device.c | 3 +++ > > net/bridge/br_private.h | 3 +++ > > 3 files changed, 17 insertions(+) > > > > Acked-by: Nikolay Aleksandrov > -- /Henrik
Re: [PATCH net-next v5 08/10] bridge: cfm: Netlink GET configuration Interface.
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 +, 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_
Re: [PATCH net-next v5 09/10] bridge: cfm: Netlink GET status Interface.
Thanks for your review. Regards Henrik The 10/14/2020 11:24, 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 +, Henrik Bjoernlund wrote: > > This is the implementation of CFM netlink status > > get information interface. > > > > Add new nested netlink attributes. These attributes are used by the > > user space to get status information. > > > > GETLINK: > > 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. > > > > 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. > > > > Signed-off-by: Henrik Bjoernlund > > Reviewed-by: Horatiu Vultur > > --- > > include/uapi/linux/if_bridge.h | 29 + > > include/uapi/linux/rtnetlink.h | 1 + > > net/bridge/br_cfm_netlink.c| 105 + > > net/bridge/br_netlink.c| 16 - > > net/bridge/br_private.h| 6 ++ > > 5 files changed, 154 insertions(+), 3 deletions(-) > > > > > > Acked-by: Nikolay Aleksandrov > > -- /Henrik
