On Mon, Jul 29, 2019 at 04:35:09PM +0200, Allan W. Nielsen wrote:

The 07/29/2019 17:21, Nikolay Aleksandrov wrote:

quoted

On 29/07/2019 16:52, Allan W. Nielsen wrote:

quoted

The 07/29/2019 15:50, Nikolay Aleksandrov wrote:

quoted

On 29/07/2019 15:22, Nikolay Aleksandrov wrote:

quoted

Hi Allan,
On 29/07/2019 15:14, Allan W. Nielsen wrote:

quoted

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:

quoted

quoted

quoted

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

quoted

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.