On Mon, Jan 18, 2021 at 20:01, Andrew Lunn <and...@lunn.ch> wrote: > On Mon, Jan 18, 2021 at 07:30:49PM +0100, Tobias Waldekranz wrote: >> On Mon, Jan 18, 2021 at 18:50, Andrew Lunn <and...@lunn.ch> wrote: >> >> 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.
