netdev - Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 07 Nov 2017 13:16:09 -0500
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic

Hi Andrew,

Andrew Lunn <andrew@...n.ch> 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?
>
> 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