[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e784e0e6-8b30-0862-e417-a6ff94790b8e@nvidia.com>
Date: Tue, 11 May 2021 12:33:08 +0300
From: Nikolay Aleksandrov <nikolay@...dia.com>
To: Linus Lüssing <linus.luessing@...3.blue>,
netdev@...r.kernel.org
Cc: Roopa Prabhu <roopa@...dia.com>, Jakub Kicinski <kuba@...nel.org>,
"David S . Miller" <davem@...emloft.net>,
bridge@...ts.linux-foundation.org, b.a.t.m.a.n@...ts.open-mesh.org,
linux-kernel@...r.kernel.org
Subject: Re: [net-next v2 09/11] net: bridge: mcast: split multicast router
state for IPv4 and IPv6
On 11/05/2021 12:29, Nikolay Aleksandrov wrote:
> On 09/05/2021 22:45, Linus Lüssing wrote:
>> A multicast router for IPv4 does not imply that the same host also is a
>> multicast router for IPv6 and vice versa.
>>
>> To reduce multicast traffic when a host is only a multicast router for
>> one of these two protocol families, keep router state for IPv4 and IPv6
>> separately. Similar to how querier state is kept separately.
>>
>> For backwards compatibility for netlink and switchdev notifications
>> these two will still only notify if a port switched from either no
>> IPv4/IPv6 multicast router to any IPv4/IPv6 multicast router or the
>> other way round. However a full netlink MDB router dump will now also
>> include a multicast router timeout for both IPv4 and IPv6.
>>
>> Signed-off-by: Linus Lüssing <linus.luessing@...3.blue>
>> ---
>> net/bridge/br_forward.c | 8 ++
>> net/bridge/br_mdb.c | 10 ++
>> net/bridge/br_multicast.c | 197 ++++++++++++++++++++++++++++++++++----
>> net/bridge/br_private.h | 6 +-
>> 4 files changed, 201 insertions(+), 20 deletions(-)
[snip]
>> +#else
>> +static inline void br_ip6_multicast_add_router(struct net_bridge *br,
>> + struct net_bridge_port *port)
>> +{
>> +}
>
> Actually that goes for multicast_add_router, too.
>
err, my bad - multicast_add_router is fine as is, sorry about that
> I'm saying all this because soon I'll be adding per-vlan multicast router support
> and these will be reusable there without any modification if they can take any list.
> Also it'll be easier to maintain one set of functions instead of multiple identical ones.
>
Powered by blists - more mailing lists