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 15:14:21 +0200 [thread overview] Message-ID: <20190729131420.tqukz55tz26jkg73@lx-anielsen.microsemi.net> (raw) In-Reply-To: <95315f9e-0d31-2d34-ba50-11e1bbc1465c@cumulusnetworks.com> The 07/29/2019 15:22, Nikolay Aleksandrov wrote: > Yes, all of the multicast code is handled differently, it doesn't go through the fdb > lookup or code at all. I don't see how you'll do a lookup in the fdb table with a > multicast mac address, take a look at br_handle_frame_finish() and you'll notice > that when a multicast dmac is detected then we use the bridge mcast code for lookups > and forwarding. Here is my thinking (needs much more elaboration, which will come if we do a patch to test it out): In br_pkt_type Rename BR_PKT_MULTICAST to BR_PKT_MULTICAST_IP Add a new type called BR_PKT_MULTICAST_L2 In br_handle_frame_finish if (is_multicast_ether_addr(dest)) { /* by definition the broadcast is also a multicast address */ if (is_broadcast_ether_addr(dest)) { pkt_type = BR_PKT_BROADCAST; local_rcv = true; } else { pkt_type = BR_PKT_MULTICAST; if (br_multicast_rcv(br, p, skb, vid)) goto drop; } } Change the code above to detect if it is a BR_PKT_MULTICAST_IP or a BR_PKT_MULTICAST_L2 In this section: switch (pkt_type) { .... } if (dst) { } else { } Add awareness to the BR_PKT_MULTICAST_L2 type, and allow it do forwarding according to the static entry if it is there. > If you're trying to achieve Rx only on the bridge of these then > why not just use Ido's tc suggestion or even the ip maddr add offload for each port ? > > If you add a multicast mac in the fdb (currently allowed, but has no effect) and you > use dev_mc_add() as suggested that'd just be a hack to pass it down and it is already > possible to achieve via other methods, no need to go through the bridge. Well, I wanted the SW bridge implementation to behave the same with an without HW offload. And also, I believe that is conceptually belongs to the MAC tables. /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 15:14:21 +0200 [thread overview] Message-ID: <20190729131420.tqukz55tz26jkg73@lx-anielsen.microsemi.net> (raw) In-Reply-To: <95315f9e-0d31-2d34-ba50-11e1bbc1465c@cumulusnetworks.com> The 07/29/2019 15:22, Nikolay Aleksandrov wrote: > Yes, all of the multicast code is handled differently, it doesn't go through the fdb > lookup or code at all. I don't see how you'll do a lookup in the fdb table with a > multicast mac address, take a look at br_handle_frame_finish() and you'll notice > that when a multicast dmac is detected then we use the bridge mcast code for lookups > and forwarding. Here is my thinking (needs much more elaboration, which will come if we do a patch to test it out): In br_pkt_type Rename BR_PKT_MULTICAST to BR_PKT_MULTICAST_IP Add a new type called BR_PKT_MULTICAST_L2 In br_handle_frame_finish if (is_multicast_ether_addr(dest)) { /* by definition the broadcast is also a multicast address */ if (is_broadcast_ether_addr(dest)) { pkt_type = BR_PKT_BROADCAST; local_rcv = true; } else { pkt_type = BR_PKT_MULTICAST; if (br_multicast_rcv(br, p, skb, vid)) goto drop; } } Change the code above to detect if it is a BR_PKT_MULTICAST_IP or a BR_PKT_MULTICAST_L2 In this section: switch (pkt_type) { .... } if (dst) { } else { } Add awareness to the BR_PKT_MULTICAST_L2 type, and allow it do forwarding according to the static entry if it is there. > If you're trying to achieve Rx only on the bridge of these then > why not just use Ido's tc suggestion or even the ip maddr add offload for each port ? > > If you add a multicast mac in the fdb (currently allowed, but has no effect) and you > use dev_mc_add() as suggested that'd just be a hack to pass it down and it is already > possible to achieve via other methods, no need to go through the bridge. Well, I wanted the SW bridge implementation to behave the same with an without HW offload. And also, I believe that is conceptually belongs to the MAC tables. /Allan
next prev parent reply other threads:[~2019-07-29 13: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 2019-07-29 12:14 ` [Bridge] " 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 [this message] 2019-07-29 13:14 ` 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=20190729131420.tqukz55tz26jkg73@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.