On 29/07/2019 16:52, Allan W. Nielsen wrote: > The 07/29/2019 15:50, Nikolay Aleksandrov wrote: >> On 29/07/2019 15:22, Nikolay Aleksandrov wrote: >>> Hi Allan, >>> On 29/07/2019 15:14, Allan W. Nielsen wrote: >>>> First of all, as mentioned further down in this thread, I realized that our >>>> implementation of the multicast floodmasks does not align with the existing SW >>>> implementation. We will change this, such that all multicast packets goes to the >>>> SW bridge. >>>> >>>> This changes things a bit, not that much. >>>> >>>> I actually think you summarized the issue we have (after changing to multicast >>>> flood-masks) right here: >>>> >>>> The 07/26/2019 12:26, Nikolay Aleksandrov wrote: >>>>>>> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This >>>>>>> traffic will always be flooded by the bridge (and also a copy will be locally sent up). >>>>>>> Thus only the flooding may need to be controlled. >>>> >>>> This seems to be exactly what we need. >>>> >>>> Assuming we have a SW bridge (br0) with 4 slave interfaces (eth0-3). We use this >>>> on a network where we want to limit the flooding of frames with dmac >>>> 01:21:6C:00:00:01 (which is non IP traffic) to eth0 and eth1. >>>> >>>> One way of doing this could potentially be to support the following command: >>>> >>>> bridge fdb add 01:21:6C:00:00:01 port eth0 >>>> bridge fdb append 01:21:6C:00:00:01 port eth1 >>>> >> >> And the fdbs become linked lists? > Yes, it will most likely become a linked list > >> So we'll increase the complexity for something that is already supported by >> ACLs (e.g. tc) and also bridge per-port multicast flood flag ? > I do not think it can be supported with the facilities we have today in tc. > > We can do half of it (copy more fraems to the CPU) with tc, but we can not limit > the floodmask of a frame with tc (say we want it to flood to 2 out of 4 slave > ports). > Why not ? You attach an egress filter for the ports and allow that dmac on only 2 of the ports. >> I'm sorry but that doesn't sound good to me for a case which is very rare and >> there are existing ways to solve without incurring performance hits or increasing >> code complexity. > I do not consider it rarely, controling the forwarding of L2 multicast frames is > quite common in the applications we are doing. > >> If you find a way to achieve this without incurring a performance hit or significant >> code complexity increase, and without breaking current use-cases (e.g. unexpected default >> forwarding behaviour changes) then please send a patch and we can discuss it further with >> all details present. People have provided enough alternatives which avoid all of the >> problems. > Will do, thanks for the guidance. > > /Allan >
