On Mon, Jan 18, 2021 at 20:01, Andrew Lunn [off-list ref] wrote:

On Mon, Jan 18, 2021 at 07:30:49PM +0100, Tobias Waldekranz wrote:

quoted

On Mon, Jan 18, 2021 at 18:50, Andrew Lunn [off-list ref] wrote:

quoted

quoted

I suppose the real solution is having userspace do some "bridge mdb add"
yoga, but since no code currently uses
MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC_DA_MGMT, I don't think there's any
way to actually achieve this. And I have no idea how to represent the
requirement that "frames with this multicast DA are only to be directed
at the CPU" in a hardware-agnostic way.

The switchdev interface for this exists, because there can be
multicast listeners on the bridge. When they join a group, they ask
the switch to put in a HOST MDB, which should cause the traffic for

That is not quite the same thing as "management" though. Adding the
group to the host MDB will not allow it to pass through blocked (in the
STP sense) ports for example. With a management entry, the switch will
trap the packet with a TO_CPU tag, which means no ingress policy can get
in the way of it reaching the CPU.

Ah, yes. I don't suppose the DA is part of the special group which the
switch will recognise as management and pass it on?

01:80:c2:00:00:00 - 01:80:c2:00:00:07
01:80:c2:00:00:08 - 01:80:c2:00:00:0f
01:80:c2:00:00:20 - 01:80:c2:00:00:27
01:80:c2:00:00:28 - 01:80:c2:00:00:2f

Unfortunately there are many protocols that live outside of the IEEE
range. ERP(S) which Rasmus was talking about uses a range assigned to
ITU IIRC. MRP a third one I believe.

The Reserved2CPU functionality has an additional deficiency vs. separate
management entries: they all use the same priority. This means that you
must assign LLDP frames to the same queue as STP for example, which is
typically not what you want. With a management entry (with priority
override) you can set them individually.