From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: David Miller <davem@davemloft.net>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic
Date: Tue, 7 Nov 2017 16:41:41 -0800 [thread overview]
Message-ID: <16bdbcfe-d2b3-5e66-f7b8-12020b732625@gmail.com> (raw)
In-Reply-To: <20171107231700.GD7601@lunn.ch>
On 11/07/2017 03:17 PM, Andrew Lunn wrote:
> On Tue, Nov 07, 2017 at 05:37:32PM -0500, Vivien Didelot wrote:
>> Hi Andrew,
>>
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>>>> In a switch case, they all translate to programming a MDB entry for
>>>> a given switch port, right?
>>>
>>> No, in fact it is the exact opposite.
>>
>> Yes, they do. The proof is you call dsa_port_mdb_add.
>
> Note that i always say switchdev.
>
> switchdev has no concept of the CPU port. All switchdev has is the
> concept of the external ports.
Correct.
>
> So when there is a join on the br0 interface, the bridge code will
> iterative over each port in the bridge, and make a switchdev call to
> each of the external ports in the bridge asking it to forward
> multicast traffic for a group to the host.
Right, and that makes sense thus far.
>
> Now, deep down in DSA, we can translate this to a dsa_port_mdb_add, on
> the CPU port. And we do that for every call the bridge makes for each
> of the external ports in the bridge.
Right, and we should actually do that, because this is a DSA specific
detail: that there is a separate management port that needs specific
treatment here.
>
> However, a pure switchdev device won't do that. It does not have a CPU
> port. It probably needs to add a match/action rule to its tables for
> the actual external port saying to forward the frame out the slow
> path.
Right, that's why DSA builds on top of switchdev for most notifications
and also generate its own for things that are inherently DSA specific.
>
>> Still, what I see here _from a switch driver point of view_ is either
>> program an MDB entry on a user port, or on its CPU port.
>
> I agree with this, if you make one change:
>
> _from a DSA switch driver point of view_
>
> However, in the general case, this is not true. We need an API which
> works for Mellonex and Netranome as well, systems without a CPU port.
We can have the exact same type of notification being sent today and
with your changes target the bridge network devices, any other driver
other than DSA which implements switchdev should just ignore that
notification when they cannot resolve this network device to something
that makes sense for their HW. In fact, Jiri and Ido (which should
probably be copied on this patch series, along with Nikolay) was adamant
to the idea:
https://lists.linux-foundation.org/pipermail/bridge/2016-November/010124.html
The usual model for notifications is that if you can interpret and act
on them, great, if you can't do nothing.
--
Florian
next prev parent reply other threads:[~2017-11-08 0:41 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 23:26 [PATCH v3 net-next 0/5] IGMP snooping for local traffic Andrew Lunn
2017-11-06 23:26 ` [PATCH v3 net-next 1/5] net: bridge: Rename mglist to host_joined Andrew Lunn
2017-11-08 1:31 ` Nikolay Aleksandrov
2017-11-08 1:40 ` Florian Fainelli
2017-11-06 23:26 ` [PATCH v3 net-next 2/5] net: bridge: Send notification when host join/leaves a group Andrew Lunn
2017-11-08 1:39 ` Nikolay Aleksandrov
2017-11-08 1:41 ` Florian Fainelli
2017-11-06 23:26 ` [PATCH v3 net-next 3/5] net: bridge: Add/del switchdev object on host join/leave Andrew Lunn
2017-11-08 1:48 ` Nikolay Aleksandrov
2017-11-06 23:26 ` [PATCH v3 net-next 4/5] net: dsa: slave: Handle switchdev host mdb add/del Andrew Lunn
2017-11-06 23:26 ` [PATCH v3 net-next 5/5] net: dsa: switch: Don't add CPU port to an mdb by default Andrew Lunn
2017-11-07 10:12 ` Sergei Shtylyov
2017-11-07 1:01 ` [PATCH v3 net-next 0/5] IGMP snooping for local traffic Stephen Hemminger
2017-11-07 17:03 ` Vivien Didelot
2017-11-07 17:42 ` Andrew Lunn
2017-11-07 18:10 ` Florian Fainelli
2017-11-07 18:16 ` Vivien Didelot
2017-11-07 21:01 ` Andrew Lunn
2017-11-07 21:18 ` Florian Fainelli
2017-11-07 22:17 ` Andrew Lunn
2017-11-07 22:37 ` Vivien Didelot
2017-11-07 23:17 ` Andrew Lunn
2017-11-08 0:41 ` Florian Fainelli [this message]
2017-11-09 18:41 ` Florian Fainelli
2017-11-09 19:30 ` Andrew Lunn
2017-11-09 19:38 ` Florian Fainelli
2017-11-09 20:21 ` Andrew Lunn
2017-11-09 20:35 ` Florian Fainelli
2017-11-09 21:13 ` Andrew Lunn
2017-11-09 21:40 ` Ido Schimmel
2017-11-07 17:34 ` Egil Hjelmeland
2017-11-07 17:58 ` Andrew Lunn
2017-11-08 15:11 ` Egil Hjelmeland
2017-11-08 15:21 ` Andrew Lunn
2017-11-08 15:53 ` Vivien Didelot
2017-11-09 2:30 ` David Miller
2017-11-09 2:47 ` David Miller
2017-11-09 14:44 ` Vivien Didelot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16bdbcfe-d2b3-5e66-f7b8-12020b732625@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.