On 01/08/2019 17:15, Nikolay Aleksandrov wrote: > 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@xxxxxxxxxxxxx> >>>> Co-developed-by: Allan W. Nielsen <allan.nielsen@xxxxxxxxxxxxx> >>>> Signed-off-by: Allan W. Nielsen <allan.nielsen@xxxxxxxxxxxxx> >>>> --- >>>> 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. :) > TBH, I'm inclined to just use proto == 0 *internally* as this even though it's reserved, we're not putting it on the wire or using it to construct packets, it's just internal use which can change into a flag if some day that value needs to be used. Obviously to user-space we need it to be a flag, we can't expose or configure it as a proto value without making it permanent uapi. I haven't looked into detail how feasible this is, just a thought that might make it simpler.
