All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Nikolay Aleksandrov <nikolay@nvidia.com>
Cc: Ido Schimmel <idosch@idosch.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Ido Schimmel <idosch@nvidia.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Roopa Prabhu <roopa@nvidia.com>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>, Jiri Pirko <jiri@nvidia.com>
Subject: Re: [PATCH net-next 6/8] net: bridge: move br_fdb_replay inside br_switchdev.c
Date: Wed, 27 Oct 2021 12:58:57 +0000	[thread overview]
Message-ID: <20211027125856.wypzqjpepceq3jsy@skbuf> (raw)
In-Reply-To: <b73e4afe-07a7-08df-cc29-c2490265f2f8@nvidia.com>

On Wed, Oct 27, 2021 at 11:28:23AM +0300, Nikolay Aleksandrov wrote:
> On 27/10/2021 11:16, Ido Schimmel wrote:
> > On Tue, Oct 26, 2021 at 05:27:41PM +0300, Vladimir Oltean wrote:
> >> br_fdb_replay is only called from switchdev code paths, so it makes
> >> sense to be disabled if switchdev is not enabled in the first place.
> >>
> >> As opposed to br_mdb_replay and br_vlan_replay which might be turned off
> >> depending on bridge support for multicast and VLANs, FDB support is
> >> always on. So moving br_mdb_replay and br_vlan_replay inside
> >> br_switchdev.c would mean adding some #ifdef's in br_switchdev.c, so we
> >> keep those where they are.
> > 
> > TBH, for consistency with br_mdb_replay() and br_vlan_replay(), it would
> > have been good to keep it where it is, but ...
> > 
> >>
> >> The reason for the movement is that in future changes there will be some
> >> code reuse between br_switchdev_fdb_notify and br_fdb_replay.
> > 
> > this seems like a good reason, so:
> > 
> > Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> > 
> > Nik, WDYT?
> > 
> 
> Good point, it'd be nice to have them all in one place, since they all deal
> specifically with switchdev we can move them to br_switchdev.c. We can also
> rename them similar to other functions in br_switchdev, e.g. br_switchdev_fdb_replay

Looks like we cam move a surprisingly large amount of code from br_mdb.c
to br_switchdev.c. The only problem is:

                                          this used to be called br_mdb_complete
                                                         |
                                                         v
net/bridge/br_switchdev.c: In function ‘br_switchdev_mdb_complete’:
net/bridge/br_switchdev.c:437:20: error: ‘struct net_bridge’ has no member named ‘multicast_lock’; did you mean ‘multicast_ctx’?
  437 |  spin_lock_bh(&br->multicast_lock);
      |                    ^~~~~~~~~~~~~~
      |                    multicast_ctx

Would you like me to introduce a set of br_multicast_lock() and
br_multicast_unlock() helpers that have shim definitions so that they
work when CONFIG_BRIDGE_IGMP_SNOOPING is disabled?

Anyway, I'd like to do this second part of refactoring in a second patch
series, if you don't mind.

  reply	other threads:[~2021-10-27 12:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 14:27 [PATCH net-next 0/8] Bridge FDB refactoring Vladimir Oltean
2021-10-26 14:27 ` [PATCH net-next 1/8] net: bridge: remove fdb_notify forward declaration Vladimir Oltean
2021-10-27  7:45   ` Ido Schimmel
2021-10-27  8:29   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 2/8] net: bridge: remove fdb_insert " Vladimir Oltean
2021-10-27  7:47   ` Ido Schimmel
2021-10-27  8:29   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 3/8] net: bridge: rename fdb_insert to fdb_add_local Vladimir Oltean
2021-10-27  7:51   ` Ido Schimmel
2021-10-27  8:31   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 4/8] net: bridge: rename br_fdb_insert to br_fdb_add_local Vladimir Oltean
2021-10-27  7:54   ` Ido Schimmel
2021-10-27  8:32   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 5/8] net: bridge: reduce indentation level in fdb_create Vladimir Oltean
2021-10-27  8:05   ` Ido Schimmel
2021-10-27  8:32   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 6/8] net: bridge: move br_fdb_replay inside br_switchdev.c Vladimir Oltean
2021-10-27  8:16   ` Ido Schimmel
2021-10-27  8:28     ` Nikolay Aleksandrov
2021-10-27 12:58       ` Vladimir Oltean [this message]
2021-10-27 13:04         ` Vladimir Oltean
2021-10-26 14:27 ` [PATCH net-next 7/8] net: bridge: create a common function for populating switchdev FDB entries Vladimir Oltean
2021-10-27  8:26   ` Ido Schimmel
2021-10-27  8:39   ` Nikolay Aleksandrov
2021-10-26 14:27 ` [PATCH net-next 8/8] net: switchdev: merge switchdev_handle_fdb_{add,del}_to_device Vladimir Oltean
2021-10-27  8:46   ` Ido Schimmel
2021-10-27 11:28     ` Vladimir Oltean
2021-10-27 14:40 ` [PATCH net-next 0/8] Bridge FDB refactoring patchwork-bot+netdevbpf
2021-10-27 14:44   ` Nikolay Aleksandrov
2021-10-27 14:46     ` Vladimir Oltean
2021-10-27 14:49       ` 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=20211027125856.wypzqjpepceq3jsy@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=idosch@nvidia.com \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=olteanv@gmail.com \
    --cc=roopa@nvidia.com \
    --cc=vivien.didelot@gmail.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.