Hi Andrew,

Andrew Lunn [off-list ref] writes:

quoted

quoted

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?

It is not quite as simple as that. Image:

brctl addbr br0
brctl addif br0 eth2
brctl addif br0 lan0

where eth2 is just a regular ethernet interface. Say there is a join
received on eth2 for group 224.42.42.42. The IGMP snooping code in the
software bridge then needs to tell lan0 to forward all multicast
traffic for 224.42.42.42 to the software bridge, so it can forward it
to eth2. The br0 interface is not involved.

Now, my patchset is not implementing this use case. But at some point,
we probably will want to implement it. We want a generic switchdev API
which says forward all the traffic for a group to the host. The host
will then decide what to do with it.

Now, your suggestion would be to pass br0 for the use case i'm
implementing here. And we could pass eth2 for the above use cases. But
for the hardware offload, it does not matter what interface the frames
are heading towards. All the offload needs to know is that the host
software bridge wants the frames.

I do understand a bit more. So when an MDB entry is programmed on a
bridge port, all we need to do is program the dedicated CPU port of a
switch port if the target bridge port isn't the switch port.

Something like:

    // the bridge code sends this mdb object:
    struct switchdev_obj_port_mdb mdb = { .orig_dev = eth2, .dev = lan0 }

    // the DSA code receives it:
    /* if the switch port isn't the target port, program its CPU port */
    dp = dsa_slave_to_port(mdb->dev)
    if (mdb->dev != mdb->orig_dev)
        dp = dp->cpu_dp;
    dsa_port_mdb_add(dp, mdb);

Doesn't this cover your use cases?


Thanks,

        Vivien