Nikolay Aleksandrov
2019-Aug-01 14:11 UTC
[Bridge] [net-next, rfc] net: bridge: mdb: Extend with multicast LLADDR
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 at microchip.com> >> Co-developed-by: Allan W. Nielsen <allan.nielsen at microchip.com> >> Signed-off-by: Allan W. Nielsen <allan.nielsen at microchip.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, > NikOops, I sent back your original patch. Here's the actually changed version I was talking about. Thanks, Nik -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-net-bridge-mdb-Extend-with-multicast-LLADDR.patch Type: text/x-patch Size: 12963 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bridge/attachments/20190801/daa3ab42/attachment.bin>
Nikolay Aleksandrov
2019-Aug-01 14:15 UTC
[Bridge] [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 at microchip.com> >>> Co-developed-by: Allan W. Nielsen <allan.nielsen at microchip.com> >>> Signed-off-by: Allan W. Nielsen <allan.nielsen at microchip.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. :)