From: Nikolay Aleksandrov <razor@blackwall.org>
To: Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Cc: mlxsw@nvidia.com, edumazet@google.com, roopa@nvidia.com,
kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net
Subject: Re: [Bridge] [PATCH net-next 0/8] bridge: mcast: Preparations for EVPN extensions
Date: Mon, 5 Dec 2022 13:55:05 +0200 [thread overview]
Message-ID: <73405dec-e1ec-e581-ba8e-83bb8343d2b0@blackwall.org> (raw)
In-Reply-To: <20221205074251.4049275-1-idosch@nvidia.com>
On 05/12/2022 09:42, Ido Schimmel wrote:
> This patchset was split from [1] and includes non-functional changes
> aimed at making it easier to add additional netlink attributes later on.
> Future extensions are available here [2].
>
> The idea behind these patches is to create an MDB configuration
> structure into which netlink messages are parsed into. The structure is
> then passed in the entry creation / deletion call chain instead of
> passing the netlink attributes themselves. The same pattern is used by
> other rtnetlink objects such as routes and nexthops.
>
> I initially tried to extend the current code, but it proved to be too
> difficult, which is why I decided to refactor it to the extensible and
> familiar pattern used by other rtnetlink objects.
>
> Tested using existing selftests and using a new selftest that will be
> submitted together with the planned extensions.
>
> No changes since initial RFC.
>
> [1] https://lore.kernel.org/netdev/20221018120420.561846-1-idosch@nvidia.com/
> [2] https://github.com/idosch/linux/commits/submit/mdb_v1
>
> Ido Schimmel (8):
> bridge: mcast: Centralize netlink attribute parsing
> bridge: mcast: Remove redundant checks
> bridge: mcast: Use MDB configuration structure where possible
> bridge: mcast: Propagate MDB configuration structure further
> bridge: mcast: Use MDB group key from configuration structure
> bridge: mcast: Remove br_mdb_parse()
> bridge: mcast: Move checks out of critical section
> bridge: mcast: Remove redundant function arguments
>
> net/bridge/br_mdb.c | 312 +++++++++++++++++++---------------------
> net/bridge/br_private.h | 7 +
> 2 files changed, 156 insertions(+), 163 deletions(-)
>
As I also commented on the RFC, nice work! Allowing user-space to manipulate and manually
install such entries is a natural extension.
One thought (not a big deal) but it would've been ideal if we could initialize the config
struct once when parsing and then pass it around as a const argument. I know that its
arguments are currently passed to functions that don't expect const, but I *think* it
could be a small change.
Thanks,
Nik
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Aleksandrov <razor@blackwall.org>
To: Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, roopa@nvidia.com, mlxsw@nvidia.com
Subject: Re: [PATCH net-next 0/8] bridge: mcast: Preparations for EVPN extensions
Date: Mon, 5 Dec 2022 13:55:05 +0200 [thread overview]
Message-ID: <73405dec-e1ec-e581-ba8e-83bb8343d2b0@blackwall.org> (raw)
In-Reply-To: <20221205074251.4049275-1-idosch@nvidia.com>
On 05/12/2022 09:42, Ido Schimmel wrote:
> This patchset was split from [1] and includes non-functional changes
> aimed at making it easier to add additional netlink attributes later on.
> Future extensions are available here [2].
>
> The idea behind these patches is to create an MDB configuration
> structure into which netlink messages are parsed into. The structure is
> then passed in the entry creation / deletion call chain instead of
> passing the netlink attributes themselves. The same pattern is used by
> other rtnetlink objects such as routes and nexthops.
>
> I initially tried to extend the current code, but it proved to be too
> difficult, which is why I decided to refactor it to the extensible and
> familiar pattern used by other rtnetlink objects.
>
> Tested using existing selftests and using a new selftest that will be
> submitted together with the planned extensions.
>
> No changes since initial RFC.
>
> [1] https://lore.kernel.org/netdev/20221018120420.561846-1-idosch@nvidia.com/
> [2] https://github.com/idosch/linux/commits/submit/mdb_v1
>
> Ido Schimmel (8):
> bridge: mcast: Centralize netlink attribute parsing
> bridge: mcast: Remove redundant checks
> bridge: mcast: Use MDB configuration structure where possible
> bridge: mcast: Propagate MDB configuration structure further
> bridge: mcast: Use MDB group key from configuration structure
> bridge: mcast: Remove br_mdb_parse()
> bridge: mcast: Move checks out of critical section
> bridge: mcast: Remove redundant function arguments
>
> net/bridge/br_mdb.c | 312 +++++++++++++++++++---------------------
> net/bridge/br_private.h | 7 +
> 2 files changed, 156 insertions(+), 163 deletions(-)
>
As I also commented on the RFC, nice work! Allowing user-space to manipulate and manually
install such entries is a natural extension.
One thought (not a big deal) but it would've been ideal if we could initialize the config
struct once when parsing and then pass it around as a const argument. I know that its
arguments are currently passed to functions that don't expect const, but I *think* it
could be a small change.
Thanks,
Nik
next prev parent reply other threads:[~2022-12-05 11:55 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 7:42 [Bridge] [PATCH net-next 0/8] bridge: mcast: Preparations for EVPN extensions Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 7:42 ` [Bridge] [PATCH net-next 1/8] bridge: mcast: Centralize netlink attribute parsing Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:34 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:34 ` Nikolay Aleksandrov
2022-12-06 9:53 ` [Bridge] " Ido Schimmel
2022-12-06 9:53 ` Ido Schimmel
2022-12-05 7:42 ` [Bridge] [PATCH net-next 2/8] bridge: mcast: Remove redundant checks Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:34 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:34 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 3/8] bridge: mcast: Use MDB configuration structure where possible Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:35 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:35 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 4/8] bridge: mcast: Propagate MDB configuration structure further Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:40 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:40 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 5/8] bridge: mcast: Use MDB group key from configuration structure Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:41 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:41 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 6/8] bridge: mcast: Remove br_mdb_parse() Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:42 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:42 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 7/8] bridge: mcast: Move checks out of critical section Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:43 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:43 ` Nikolay Aleksandrov
2022-12-05 7:42 ` [Bridge] [PATCH net-next 8/8] bridge: mcast: Remove redundant function arguments Ido Schimmel
2022-12-05 7:42 ` Ido Schimmel
2022-12-05 11:43 ` [Bridge] " Nikolay Aleksandrov
2022-12-05 11:43 ` Nikolay Aleksandrov
2022-12-05 11:55 ` Nikolay Aleksandrov [this message]
2022-12-05 11:55 ` [PATCH net-next 0/8] bridge: mcast: Preparations for EVPN extensions Nikolay Aleksandrov
2022-12-06 9:58 ` [Bridge] " Ido Schimmel
2022-12-06 9:58 ` Ido Schimmel
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=73405dec-e1ec-e581-ba8e-83bb8343d2b0@blackwall.org \
--to=razor@blackwall.org \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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.