Hi Andrew,

Andrew Lunn [off-list ref] writes:

Then starts the work passing down to the hardware that the host has
joined/left a group. The existing switchdev mdb object cannot be used,
since the semantics are different. The existing
SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
group should be forwarded out that port of the switch. However here we
require the exact opposite. We want multicast frames for the group
received on the port to the forwarded to the host. Hence add a new
object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
forward to the host. This new object is then propagated through the
DSA layers. No DSA driver changes should be needed, this should just
work...

The patchset looks good. I would like to ask you some details though,
because I don't understand why the semantics are different.

Technically, what happens is that an MDB entry is programmed on the
bridge interface. From the _bridge point of view_, there is no technical
difference as in programming an MDB entry on a bridged port. Correct?

So we can simply use an mdb switchdev_obj_port_mdb structure with:

    mdb.orig_dev = mdb.dev = br->dev;

The structure will still be propagated to all bridge members as usual
and switchdev users can check the above fields.

From the _DSA point of view_, mdb->orig_dev == dp->bridge_dev would mean

that we must program dp->cpu_dp, the bridge port's dedicated CPU port.

To me it looks like the only confusion here is in the name of the
switchdev object, where SWITCHDEV_OBJ_ID_PORT_MDB and
switchdev_obj_port_mdb must be in fact SWITCHDEV_OBJ_ID_MDB and
switchdev_obj_mdb. Or I am missing something?

I just want to make sure I understand the whole picture correctly here.
About the patchset itself, introducing SWITCHDEV_OBJ_ID_HOST_MDB seems
to be only meant to avoid a noisy global renaming, in which case I'm
fine with that.

My only concern is that it looks like we'll have the same issue with
programming e.g. VLAN or static FDB entries on the bridge interface, in
which case the correct way to go would be to use and check orig_dev.


Thanks,

        Vivien