[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <696c9bcc-f7e3-3d22-69c4-cdf4f37280a9@cumulusnetworks.com>
Date: Thu, 1 Aug 2019 17:15:46 +0300
From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>, idosch@...lanox.com,
andrew@...n.ch, allan.nielsen@...rochip.com
Cc: davem@...emloft.net, roopa@...ulusnetworks.com, petrm@...lanox.com,
tglx@...utronix.de, fw@...len.de, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org
Subject: Re: [net-next,rfc] net: bridge: mdb: Extend with multicast LLADDR
On 01/08/2019 17:11, Nikolay Aleksandrov wrote:
> On 01/08/2019 17:07, Nikolay Aleksandrov wrote:
>> Hi Horatiu,
>> Overall I think MDB is the right way, we'd like to contain the multicast code.
>> A few comments below.
>>
>> On 01/08/2019 15:50, Horatiu Vultur wrote:
> [snip]
>>>
>>> Signed-off-by: Horatiu Vultur <horatiu.vultur@...rochip.com>
>>> Co-developed-by: Allan W. Nielsen <allan.nielsen@...rochip.com>
>>> Signed-off-by: Allan W. Nielsen <allan.nielsen@...rochip.com>
>>> ---
>>> include/linux/if_bridge.h | 1 +
>>> include/uapi/linux/if_bridge.h | 1 +
>>> net/bridge/br_device.c | 7 +++++--
>>> net/bridge/br_forward.c | 3 ++-
>>> net/bridge/br_input.c | 13 ++++++++++--
>>> net/bridge/br_mdb.c | 47 +++++++++++++++++++++++++++++++++++-------
>>> net/bridge/br_multicast.c | 4 +++-
>>> net/bridge/br_private.h | 3 ++-
>>> 8 files changed, 64 insertions(+), 15 deletions(-)
>>>
>>
>> Overall I don't think we need this BR_PKT_MULTICAST_L2, we could do the below much
>> easier and without the checks if you use a per-mdb flag that says it's to be treated
>> as a MULTICAST_L2 entry. Then you remove all of the BR_PKT_MULTICAST_L2 code (see the
>> attached patch based on this one for example). and continue processing it as it is processed today.
>> We'll keep the fast-path with minimal number of new conditionals.
>>
>> Something like the patch I've attached to this reply, note that it is not complete
>> just to show the intent, you'll have to re-work br_mdb_notify() to make it proper
>> and there're most probably other details I've missed. If you find even better/less
>> complex way to do it then please do.
>>
>> Cheers,
>> Nik
>
> Oops, I sent back your original patch. Here's the actually changed version
> I was talking about.
>
> Thanks,
> Nik
>
>
>
The querier exists change is a hack just to get the point, I'd prefer
to re-write that portion in a better way which makes more sense, i.e.
get that check out of there since it doesn't mean that an actual querier
exists. :)
Powered by blists - more mailing lists