public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>, <netdev@vger.kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	"Vivien Didelot" <vivien.didelot@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	Roopa Prabhu <roopa@nvidia.com>, Jiri Pirko <jiri@nvidia.com>,
	Ido Schimmel <idosch@nvidia.com>,
	Rafael Richter <rafael.richter@gin.de>,
	Daniel Klauer <daniel.klauer@gin.de>,
	Tobias Waldekranz <tobias@waldekranz.com>
Subject: Re: [PATCH v2 net-next 1/8] net: bridge: vlan: notify switchdev only when something changed
Date: Tue, 15 Feb 2022 10:54:26 +0200	[thread overview]
Message-ID: <bcb8c699-4abc-d458-a694-d975398f1c57@nvidia.com> (raw)
In-Reply-To: <20220214233111.1586715-2-vladimir.oltean@nxp.com>

On 15/02/2022 01:31, Vladimir Oltean wrote:
> Currently, when a VLAN entry is added multiple times in a row to a
> bridge port, nbp_vlan_add() calls br_switchdev_port_vlan_add() each
> time, even if the VLAN already exists and nothing about it has changed:
> 
> bridge vlan add dev lan12 vid 100 master static
> 
> Similarly, when a VLAN is added multiple times in a row to a bridge,
> br_vlan_add_existing() doesn't filter at all the calls to
> br_switchdev_port_vlan_add():
> 
> bridge vlan add dev br0 vid 100 self
> 
> This behavior makes driver-level accounting of VLANs impossible, since
> it is enough for a single deletion event to remove a VLAN, but the
> addition event can be emitted an unlimited number of times.
> 
> The cause for this can be identified as follows: we rely on
> __vlan_add_flags() to retroactively tell us whether it has changed
> anything about the VLAN flags or VLAN group pvid. So we'd first have to
> call __vlan_add_flags() before calling br_switchdev_port_vlan_add(), in
> order to have access to the "bool *changed" information. But we don't
> want to change the event ordering, because we'd have to revert the
> struct net_bridge_vlan changes we've made if switchdev returns an error.
> 
> So to solve this, we need another function that tells us whether any
> change is going to occur in the VLAN or VLAN group, _prior_ to calling
> __vlan_add_flags(). In fact, we even make __vlan_add_flags() return void.
> 
> With this lookahead function in place, we can avoid notifying switchdev
> if nothing changed for the VLAN and VLAN group.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> v1->v2: drop the br_vlan_restore_existing() approach, just figure out
>         ahead of time what will change.
> 
>  net/bridge/br_vlan.c | 71 ++++++++++++++++++++++++++++----------------
>  1 file changed, 46 insertions(+), 25 deletions(-)
> 
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 1402d5ca242d..c5355695c976 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -34,36 +34,29 @@ static struct net_bridge_vlan *br_vlan_lookup(struct rhashtable *tbl, u16 vid)
>  	return rhashtable_lookup_fast(tbl, &vid, br_vlan_rht_params);
>  }
>  
> -static bool __vlan_add_pvid(struct net_bridge_vlan_group *vg,
> +static void __vlan_add_pvid(struct net_bridge_vlan_group *vg,
>  			    const struct net_bridge_vlan *v)
>  {
>  	if (vg->pvid == v->vid)
> -		return false;
> +		return;
>  
>  	smp_wmb();
>  	br_vlan_set_pvid_state(vg, v->state);
>  	vg->pvid = v->vid;
> -
> -	return true;
>  }
>  
> -static bool __vlan_delete_pvid(struct net_bridge_vlan_group *vg, u16 vid)
> +static void __vlan_delete_pvid(struct net_bridge_vlan_group *vg, u16 vid)
>  {
>  	if (vg->pvid != vid)
> -		return false;
> +		return;
>  
>  	smp_wmb();
>  	vg->pvid = 0;
> -
> -	return true;
>  }
>  
> -/* return true if anything changed, false otherwise */
> -static bool __vlan_add_flags(struct net_bridge_vlan *v, u16 flags)
> +static void __vlan_add_flags(struct net_bridge_vlan *v, u16 flags)
>  {
>  	struct net_bridge_vlan_group *vg;
> -	u16 old_flags = v->flags;
> -	bool ret;
>  
>  	if (br_vlan_is_master(v))
>  		vg = br_vlan_group(v->br);
> @@ -71,16 +64,36 @@ static bool __vlan_add_flags(struct net_bridge_vlan *v, u16 flags)
>  		vg = nbp_vlan_group(v->port);
>  
>  	if (flags & BRIDGE_VLAN_INFO_PVID)
> -		ret = __vlan_add_pvid(vg, v);
> +		__vlan_add_pvid(vg, v);
>  	else
> -		ret = __vlan_delete_pvid(vg, v->vid);
> +		__vlan_delete_pvid(vg, v->vid);
>  
>  	if (flags & BRIDGE_VLAN_INFO_UNTAGGED)
>  		v->flags |= BRIDGE_VLAN_INFO_UNTAGGED;
>  	else
>  		v->flags &= ~BRIDGE_VLAN_INFO_UNTAGGED;
> +}
> +
> +/* return true if anything will change as a result of __vlan_add_flags,
> + * false otherwise
> + */
> +static bool __vlan_flags_would_change(struct net_bridge_vlan *v, u16 flags)
> +{
> +	struct net_bridge_vlan_group *vg;
> +	u16 old_flags = v->flags;
> +	bool pvid_changed;
>  
> -	return ret || !!(old_flags ^ v->flags);
> +	if (br_vlan_is_master(v))
> +		vg = br_vlan_group(v->br);
> +	else
> +		vg = nbp_vlan_group(v->port);
> +
> +	if (flags & BRIDGE_VLAN_INFO_PVID)
> +		pvid_changed = (vg->pvid == v->vid);
> +	else
> +		pvid_changed = (vg->pvid != v->vid);
> +
> +	return pvid_changed || !!(old_flags ^ v->flags);
>  }

These two have to depend on each other, otherwise it's error-prone and
surely in the future someone will forget to update both.
How about add a "commit" argument to __vlan_add_flags and possibly rename
it to __vlan_update_flags, then add 2 small helpers like __vlan_update_flags_precommit
with commit == false and __vlan_update_flags_commit with commit == true.
Or some other naming, the point is to always use the same flow and checks
when updating the flags to make sure people don't forget.

>  
>  static int __vlan_vid_add(struct net_device *dev, struct net_bridge *br,
> @@ -672,9 +685,13 @@ static int br_vlan_add_existing(struct net_bridge *br,
>  {
>  	int err;
>  
> -	err = br_switchdev_port_vlan_add(br->dev, vlan->vid, flags, extack);
> -	if (err && err != -EOPNOTSUPP)
> -		return err;
> +	*changed = __vlan_flags_would_change(vlan, flags);
> +	if (*changed) {
> +		err = br_switchdev_port_vlan_add(br->dev, vlan->vid, flags,
> +						 extack);
> +		if (err && err != -EOPNOTSUPP)
> +			return err;
> +	}

You should revert *changed to false in the error path below,
otherwise we will emit a notification without anything changed
if the br_vlan_is_brentry(vlan)) { } block errors out.

>  
>  	if (!br_vlan_is_brentry(vlan)) {
>  		/* Trying to change flags of non-existent bridge vlan */
> @@ -696,8 +713,7 @@ static int br_vlan_add_existing(struct net_bridge *br,
>  		br_multicast_toggle_one_vlan(vlan, true);
>  	}
>  
> -	if (__vlan_add_flags(vlan, flags))
> -		*changed = true;
> +	__vlan_add_flags(vlan, flags);
>  
>  	return 0;
>  
> @@ -1247,11 +1263,16 @@ int nbp_vlan_add(struct net_bridge_port *port, u16 vid, u16 flags,
>  	*changed = false;
>  	vlan = br_vlan_find(nbp_vlan_group(port), vid);
>  	if (vlan) {
> -		/* Pass the flags to the hardware bridge */
> -		ret = br_switchdev_port_vlan_add(port->dev, vid, flags, extack);
> -		if (ret && ret != -EOPNOTSUPP)
> -			return ret;
> -		*changed = __vlan_add_flags(vlan, flags);
> +		*changed = __vlan_flags_would_change(vlan, flags);
> +		if (*changed) {
> +			/* Pass the flags to the hardware bridge */
> +			ret = br_switchdev_port_vlan_add(port->dev, vid,
> +							 flags, extack);
> +			if (ret && ret != -EOPNOTSUPP)
> +				return ret;
> +		}
> +
> +		__vlan_add_flags(vlan, flags);
>  
>  		return 0;
>  	}


  parent reply	other threads:[~2022-02-15  8:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 23:31 [PATCH v2 net-next 0/8] Replay and offload host VLAN entries in DSA Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 1/8] net: bridge: vlan: notify switchdev only when something changed Vladimir Oltean
2022-02-15  0:05   ` Vladimir Oltean
2022-02-15  8:54   ` Nikolay Aleksandrov [this message]
2022-02-15  9:54     ` Vladimir Oltean
2022-02-15 10:10       ` Vladimir Oltean
2022-02-15 10:15         ` Nikolay Aleksandrov
2022-02-15 10:12       ` Nikolay Aleksandrov
2022-02-15 10:30         ` Vladimir Oltean
2022-02-15 11:08           ` Nikolay Aleksandrov
2022-02-15 11:10             ` Nikolay Aleksandrov
2022-02-15 14:36             ` Vladimir Oltean
2022-02-15 15:38             ` Vladimir Oltean
2022-02-15 15:44               ` Nikolay Aleksandrov
2022-02-15 15:52                 ` Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 2/8] net: bridge: switchdev: differentiate new VLANs from changed ones Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 3/8] net: bridge: make nbp_switchdev_unsync_objs() follow reverse order of sync() Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 4/8] net: bridge: switchdev: replay all VLAN groups Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 5/8] net: switchdev: rename switchdev_lower_dev_find to switchdev_lower_dev_find_rcu Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 6/8] net: switchdev: introduce switchdev_handle_port_obj_{add,del} for foreign interfaces Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 7/8] net: dsa: add explicit support for host bridge VLANs Vladimir Oltean
2022-02-14 23:31 ` [PATCH v2 net-next 8/8] net: dsa: offload bridge port VLANs on foreign interfaces Vladimir Oltean

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=bcb8c699-4abc-d458-a694-d975398f1c57@nvidia.com \
    --to=nikolay@nvidia.com \
    --cc=andrew@lunn.ch \
    --cc=daniel.klauer@gin.de \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=rafael.richter@gin.de \
    --cc=roopa@nvidia.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox