On Mon, Jul 29, 2019 at 04:35:09PM +0200, Allan W. Nielsen wrote: > The 07/29/2019 17:21, Nikolay Aleksandrov wrote: > > 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. > Because we want a solution which we eventually can offload in HW. And the HW > facilities we have is doing ingress processing (we have no egress ACLs in this > design), and if we try to offload an egress rule, with an ingress HW facility, > then we will run into other issues. Can you please clarify what you're trying to achieve? I just read the thread again and my impression is that you're trying to locally receive packets with a certain link layer multicast address. Nik suggested SIOCADDMULTI and I suggested a tc filter to get the packet to the CPU. If you now want to limit the ports to which this packet is flooded, then you can use tc filters in *software*: # tc qdisc add dev eth2 clsact # tc filter add dev eth2 egress pref 1 flower skip_hw \ dst_mac 01:21:6C:00:00:01 action drop If you want to forward the packet in hardware and locally receive it, you can chain several mirred action and then a trap action. Both options avoid HW egress ACLs which your design does not support.
