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 04/11] bridge: cfm: Kernel space implementation of CFM.
Date: Tue, 6 Oct 2020 14:29:37 +0000	[thread overview]
Message-ID: <719888fec794af74b375f589bc2d185fea8fc2e1.camel@nvidia.com> (raw)
In-Reply-To: <20201001103019.1342470-5-henrik.bjoernlund@microchip.com>

On Thu, 2020-10-01 at 10:30 +0000, Henrik Bjoernlund wrote:
> This is the first commit of 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<E2><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.
> 
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> ---

Thank you for breaking the big patch into 3 smaller pieces, but could you please
name them appropriately? I'm sure they add different things, so just give them
something more descriptive. Having the same subject for 3 patches looks odd.

>  include/uapi/linux/cfm_bridge.h |  23 +++
>  net/bridge/Makefile             |   2 +
>  net/bridge/br_cfm.c             | 263 ++++++++++++++++++++++++++++++++
>  net/bridge/br_private_cfm.h     |  61 ++++++++
>  4 files changed, 349 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
> 
[snip]
> +
> +	mep = kzalloc(sizeof(*mep), GFP_KERNEL);
> +	if (!mep)
> +		return -ENOMEM;
> +
> +	mep->create = *create;
> +	mep->instance = instance;
> +	rcu_assign_pointer(mep->b_port, p);
> +
> +	INIT_HLIST_HEAD(&mep->peer_mep_list);
> +
> +	hlist_add_tail_rcu(&mep->head, &br->mep_list);
> +
> +	return 0;
> +}
> +
> +static void mep_delete_implementation(struct net_bridge *br,
> +				      struct br_cfm_mep *mep)
> +{
> +	struct br_cfm_peer_mep *peer_mep;
> +
> +	ASSERT_RTNL();
> +
> +	/* Empty and free peer MEP list */
> +	hlist_for_each_entry(peer_mep, &mep->peer_mep_list, head) {

hlist_for_each_entry_safe()

> +		hlist_del_rcu(&peer_mep->head);
> +		kfree_rcu(peer_mep, rcu);
> +	}
> +
> +	RCU_INIT_POINTER(mep->b_port, NULL);
> +	hlist_del_rcu(&mep->head);
> +	kfree_rcu(mep, rcu);
> +}


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 04/11] bridge: cfm: Kernel space implementation of CFM.
Date: Tue, 6 Oct 2020 14:29:37 +0000	[thread overview]
Message-ID: <719888fec794af74b375f589bc2d185fea8fc2e1.camel@nvidia.com> (raw)
In-Reply-To: <20201001103019.1342470-5-henrik.bjoernlund@microchip.com>

On Thu, 2020-10-01 at 10:30 +0000, Henrik Bjoernlund wrote:
> This is the first commit of 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<E2><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.
> 
> Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> ---

Thank you for breaking the big patch into 3 smaller pieces, but could you please
name them appropriately? I'm sure they add different things, so just give them
something more descriptive. Having the same subject for 3 patches looks odd.

>  include/uapi/linux/cfm_bridge.h |  23 +++
>  net/bridge/Makefile             |   2 +
>  net/bridge/br_cfm.c             | 263 ++++++++++++++++++++++++++++++++
>  net/bridge/br_private_cfm.h     |  61 ++++++++
>  4 files changed, 349 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
> 
[snip]
> +
> +	mep = kzalloc(sizeof(*mep), GFP_KERNEL);
> +	if (!mep)
> +		return -ENOMEM;
> +
> +	mep->create = *create;
> +	mep->instance = instance;
> +	rcu_assign_pointer(mep->b_port, p);
> +
> +	INIT_HLIST_HEAD(&mep->peer_mep_list);
> +
> +	hlist_add_tail_rcu(&mep->head, &br->mep_list);
> +
> +	return 0;
> +}
> +
> +static void mep_delete_implementation(struct net_bridge *br,
> +				      struct br_cfm_mep *mep)
> +{
> +	struct br_cfm_peer_mep *peer_mep;
> +
> +	ASSERT_RTNL();
> +
> +	/* Empty and free peer MEP list */
> +	hlist_for_each_entry(peer_mep, &mep->peer_mep_list, head) {

hlist_for_each_entry_safe()

> +		hlist_del_rcu(&peer_mep->head);
> +		kfree_rcu(peer_mep, rcu);
> +	}
> +
> +	RCU_INIT_POINTER(mep->b_port, NULL);
> +	hlist_del_rcu(&mep->head);
> +	kfree_rcu(mep, rcu);
> +}


  reply	other threads:[~2020-10-06 14:29 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 [this message]
2020-10-06 14:29     ` 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
2020-10-06 14:44     ` [Bridge] " 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=719888fec794af74b375f589bc2d185fea8fc2e1.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.