From: "Allan W. Nielsen" <allan.nielsen@microchip.com> To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Cc: Horatiu Vultur <horatiu.vultur@microchip.com>, <roopa@cumulusnetworks.com>, <davem@davemloft.net>, <bridge@lists.linux-foundation.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups Date: Mon, 29 Jul 2019 14:14:10 +0200 [thread overview] Message-ID: <20190729121409.wa47uelw5f6l4vs4@lx-anielsen.microsemi.net> (raw) In-Reply-To: <b755f613-e6d8-a2e6-16cd-6f13ec0a6ddc@cumulusnetworks.com> Hi Nikolay, First of all, as mentioned further down in this thread, I realized that our implementation of the multicast floodmasks does not align with the existing SW implementation. We will change this, such that all multicast packets goes to the SW bridge. This changes things a bit, not that much. I actually think you summarized the issue we have (after changing to multicast flood-masks) right here: The 07/26/2019 12:26, Nikolay Aleksandrov wrote: > >> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This > >> traffic will always be flooded by the bridge (and also a copy will be locally sent up). > >> Thus only the flooding may need to be controlled. This seems to be exactly what we need. Assuming we have a SW bridge (br0) with 4 slave interfaces (eth0-3). We use this on a network where we want to limit the flooding of frames with dmac 01:21:6C:00:00:01 (which is non IP traffic) to eth0 and eth1. One way of doing this could potentially be to support the following command: bridge fdb add 01:21:6C:00:00:01 port eth0 bridge fdb append 01:21:6C:00:00:01 port eth1 On 25/07/2019 16:06, Nikolay Aleksandrov wrote: > >>>>>> In general NLM_F_APPEND is only used in vxlan, the bridge does not > >>>>>> handle that flag at all. FDB is only for *unicast*, nothing is joined > >>>>>> and no multicast should be used with fdbs. MDB is used for multicast > >>>>>> handling, but both of these are used for forwarding. This is true, and this should have been addressed in the patch, we were too focused on setting up the offload patch in the driver, and forgot to do the SW implementation. Do you see any issues in supporting this flag, and updating the SW forwarding in br_handle_frame_finish such that it can support/allow a FDB entry to be a multicast? /Allan
WARNING: multiple messages have this Message-ID (diff)
From: "Allan W. Nielsen" <allan.nielsen@microchip.com> To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, davem@davemloft.net, Horatiu Vultur <horatiu.vultur@microchip.com> Subject: Re: [Bridge] [PATCH] net: bridge: Allow bridge to joing multicast groups Date: Mon, 29 Jul 2019 14:14:10 +0200 [thread overview] Message-ID: <20190729121409.wa47uelw5f6l4vs4@lx-anielsen.microsemi.net> (raw) In-Reply-To: <b755f613-e6d8-a2e6-16cd-6f13ec0a6ddc@cumulusnetworks.com> Hi Nikolay, First of all, as mentioned further down in this thread, I realized that our implementation of the multicast floodmasks does not align with the existing SW implementation. We will change this, such that all multicast packets goes to the SW bridge. This changes things a bit, not that much. I actually think you summarized the issue we have (after changing to multicast flood-masks) right here: The 07/26/2019 12:26, Nikolay Aleksandrov wrote: > >> Actually you mentioned non-IP traffic, so the querier stuff is not a problem. This > >> traffic will always be flooded by the bridge (and also a copy will be locally sent up). > >> Thus only the flooding may need to be controlled. This seems to be exactly what we need. Assuming we have a SW bridge (br0) with 4 slave interfaces (eth0-3). We use this on a network where we want to limit the flooding of frames with dmac 01:21:6C:00:00:01 (which is non IP traffic) to eth0 and eth1. One way of doing this could potentially be to support the following command: bridge fdb add 01:21:6C:00:00:01 port eth0 bridge fdb append 01:21:6C:00:00:01 port eth1 On 25/07/2019 16:06, Nikolay Aleksandrov wrote: > >>>>>> In general NLM_F_APPEND is only used in vxlan, the bridge does not > >>>>>> handle that flag at all. FDB is only for *unicast*, nothing is joined > >>>>>> and no multicast should be used with fdbs. MDB is used for multicast > >>>>>> handling, but both of these are used for forwarding. This is true, and this should have been addressed in the patch, we were too focused on setting up the offload patch in the driver, and forgot to do the SW implementation. Do you see any issues in supporting this flag, and updating the SW forwarding in br_handle_frame_finish such that it can support/allow a FDB entry to be a multicast? /Allan
next prev parent reply other threads:[~2019-07-29 12:14 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-25 11:44 [PATCH] net: bridge: Allow bridge to joing multicast groups Horatiu Vultur 2019-07-25 11:44 ` [Bridge] " Horatiu Vultur 2019-07-25 13:06 ` Nikolay Aleksandrov 2019-07-25 13:06 ` [Bridge] " Nikolay Aleksandrov 2019-07-25 13:21 ` Nikolay Aleksandrov 2019-07-25 13:21 ` [Bridge] " Nikolay Aleksandrov 2019-07-25 14:21 ` Horatiu Vultur 2019-07-25 14:21 ` [Bridge] " Horatiu Vultur 2019-07-26 8:41 ` Nikolay Aleksandrov 2019-07-26 8:41 ` [Bridge] " Nikolay Aleksandrov 2019-07-26 9:26 ` Nikolay Aleksandrov 2019-07-26 9:26 ` [Bridge] " Nikolay Aleksandrov 2019-07-26 12:02 ` Horatiu Vultur 2019-07-26 12:02 ` [Bridge] " Horatiu Vultur 2019-07-26 12:31 ` Nikolay Aleksandrov 2019-07-26 12:31 ` [Bridge] " Nikolay Aleksandrov 2019-07-29 12:14 ` Allan W. Nielsen [this message] 2019-07-29 12:14 ` Allan W. Nielsen 2019-07-29 12:22 ` Nikolay Aleksandrov 2019-07-29 12:22 ` [Bridge] " Nikolay Aleksandrov 2019-07-29 12:50 ` Nikolay Aleksandrov 2019-07-29 12:50 ` [Bridge] " Nikolay Aleksandrov 2019-07-29 13:14 ` Allan W. Nielsen 2019-07-29 13:14 ` [Bridge] " Allan W. Nielsen 2019-07-29 13:42 ` Nikolay Aleksandrov 2019-07-29 13:42 ` [Bridge] " Nikolay Aleksandrov 2019-07-29 13:52 ` Allan W. Nielsen 2019-07-29 13:52 ` [Bridge] " Allan W. Nielsen 2019-07-29 14:21 ` Nikolay Aleksandrov 2019-07-29 14:21 ` [Bridge] " Nikolay Aleksandrov 2019-07-29 14:35 ` Allan W. Nielsen 2019-07-29 14:35 ` [Bridge] " Allan W. Nielsen 2019-07-29 17:51 ` Ido Schimmel 2019-07-29 17:51 ` [Bridge] " Ido Schimmel 2019-07-30 6:27 ` Allan W. Nielsen 2019-07-30 6:27 ` [Bridge] " Allan W. Nielsen 2019-07-30 7:06 ` Ido Schimmel 2019-07-30 7:06 ` [Bridge] " Ido Schimmel 2019-07-30 8:30 ` Allan W. Nielsen 2019-07-30 8:30 ` [Bridge] " Allan W. Nielsen 2019-07-30 8:58 ` Nikolay Aleksandrov 2019-07-30 8:58 ` [Bridge] " Nikolay Aleksandrov 2019-07-30 9:21 ` Allan W. Nielsen 2019-07-30 9:21 ` [Bridge] " Allan W. Nielsen 2019-07-30 9:55 ` Nikolay Aleksandrov 2019-07-30 9:55 ` [Bridge] " Nikolay Aleksandrov 2019-07-30 11:23 ` Allan W. Nielsen 2019-07-30 11:23 ` [Bridge] " Allan W. Nielsen 2019-07-30 10:04 ` Ido Schimmel 2019-07-30 10:04 ` [Bridge] " Ido Schimmel 2019-07-30 12:19 ` Allan W. Nielsen 2019-07-30 12:19 ` [Bridge] " Allan W. Nielsen 2019-07-30 14:34 ` Andrew Lunn 2019-07-30 14:34 ` [Bridge] " Andrew Lunn 2019-07-30 19:00 ` Allan W. Nielsen 2019-07-30 19:00 ` [Bridge] " Allan W. Nielsen 2019-07-31 3:31 ` Andrew Lunn 2019-07-31 3:31 ` [Bridge] " Andrew Lunn 2019-07-31 8:01 ` Allan W. Nielsen 2019-07-31 8:01 ` [Bridge] " Allan W. Nielsen 2019-07-31 13:45 ` Andrew Lunn 2019-07-31 13:45 ` [Bridge] " Andrew Lunn 2019-07-31 19:38 ` Allan W. Nielsen 2019-07-31 19:38 ` [Bridge] " Allan W. Nielsen 2019-08-01 14:22 ` Allan W. Nielsen 2019-08-01 14:22 ` [Bridge] " Allan W. Nielsen 2019-07-26 13:46 ` Andrew Lunn 2019-07-26 13:46 ` [Bridge] " Andrew Lunn 2019-07-26 19:50 ` Allan W. Nielsen 2019-07-26 19:50 ` [Bridge] " Allan W. Nielsen 2019-07-27 3:02 ` Andrew Lunn 2019-07-27 3:02 ` [Bridge] " Andrew Lunn 2019-07-28 19:15 ` Allan W. Nielsen 2019-07-28 19:15 ` [Bridge] " Allan W. Nielsen 2019-07-28 23:07 ` Andrew Lunn 2019-07-28 23:07 ` [Bridge] " Andrew Lunn 2019-07-29 6:09 ` Ido Schimmel 2019-07-29 6:09 ` [Bridge] " Ido Schimmel 2019-07-29 12:43 ` Allan W. Nielsen 2019-07-29 12:43 ` [Bridge] " Allan W. Nielsen 2019-08-01 19:17 ` Vivien Didelot 2019-08-01 19:17 ` [Bridge] " Vivien Didelot 2019-08-01 19:48 ` Horatiu Vultur 2019-08-01 19:48 ` [Bridge] " Horatiu Vultur 2019-08-01 20:08 ` Vivien Didelot 2019-08-01 20:08 ` [Bridge] " 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=20190729121409.wa47uelw5f6l4vs4@lx-anielsen.microsemi.net \ --to=allan.nielsen@microchip.com \ --cc=bridge@lists.linux-foundation.org \ --cc=davem@davemloft.net \ --cc=horatiu.vultur@microchip.com \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nikolay@cumulusnetworks.com \ --cc=roopa@cumulusnetworks.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: linkBe 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.