From: Ido Schimmel <idosch@idosch.org>
To: "Allan W. Nielsen" <allan.nielsen@microchip.com>
Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
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 20:51:36 +0300 [thread overview]
Message-ID: <20190729175136.GA28572@splinter> (raw)
In-Reply-To: <20190729143508.tcyebbvleppa242d@lx-anielsen.microsemi.net>
On Mon, Jul 29, 2019 at 04:35:09PM +0200, Allan W. Nielsen wrote:
> The 07/29/2019 17:21, Nikolay Aleksandrov wrote:
> > On 29/07/2019 16:52, Allan W. Nielsen wrote:
> > > The 07/29/2019 15:50, Nikolay Aleksandrov wrote:
> > >> On 29/07/2019 15:22, Nikolay Aleksandrov wrote:
> > >>> Hi Allan,
> > >>> On 29/07/2019 15:14, Allan W. Nielsen wrote:
> > >>>> 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
> > >> And the fdbs become linked lists?
> > > Yes, it will most likely become a linked list
> > >
> > >> So we'll increase the complexity for something that is already supported by
> > >> ACLs (e.g. tc) and also bridge per-port multicast flood flag ?
> > > I do not think it can be supported with the facilities we have today in tc.
> > >
> > > We can do half of it (copy more fraems to the CPU) with tc, but we can not limit
> > > the floodmask of a frame with tc (say we want it to flood to 2 out of 4 slave
> > > ports).
> > Why not ? You attach an egress filter for the ports and allow that dmac on only
> > 2 of the ports.
> Because we want a solution which we eventually can offload in HW. And the HW
> facilities we have is doing ingress processing (we have no egress ACLs in this
> design), and if we try to offload an egress rule, with an ingress HW facility,
> then we will run into other issues.
Can you please clarify what you're trying to achieve? I just read the
thread again and my impression is that you're trying to locally receive
packets with a certain link layer multicast address. Nik suggested
SIOCADDMULTI and I suggested a tc filter to get the packet to the CPU.
If you now want to limit the ports to which this packet is flooded, then
you can use tc filters in *software*:
# tc qdisc add dev eth2 clsact
# tc filter add dev eth2 egress pref 1 flower skip_hw \
dst_mac 01:21:6C:00:00:01 action drop
If you want to forward the packet in hardware and locally receive it,
you can chain several mirred action and then a trap action.
Both options avoid HW egress ACLs which your design does not support.
next prev parent reply other threads:[~2019-07-29 17:51 UTC|newest]
Thread overview: 43+ 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 13:06 ` Nikolay Aleksandrov
2019-07-25 13:21 ` Nikolay Aleksandrov
2019-07-25 14:21 ` Horatiu Vultur
2019-07-26 8:41 ` Nikolay Aleksandrov
2019-07-26 9:26 ` Nikolay Aleksandrov
2019-07-26 12:02 ` Horatiu Vultur
2019-07-26 12:31 ` Nikolay Aleksandrov
2019-07-29 12:14 ` Allan W. Nielsen
2019-07-29 12:22 ` Nikolay Aleksandrov
2019-07-29 12:50 ` Nikolay Aleksandrov
2019-07-29 13:14 ` Allan W. Nielsen
2019-07-29 13:42 ` Nikolay Aleksandrov
2019-07-29 13:52 ` Allan W. Nielsen
2019-07-29 14:21 ` Nikolay Aleksandrov
2019-07-29 14:35 ` Allan W. Nielsen
2019-07-29 17:51 ` Ido Schimmel [this message]
2019-07-30 6:27 ` Allan W. Nielsen
2019-07-30 7:06 ` Ido Schimmel
2019-07-30 8:30 ` Allan W. Nielsen
2019-07-30 8:58 ` Nikolay Aleksandrov
2019-07-30 9:21 ` Allan W. Nielsen
2019-07-30 9:55 ` Nikolay Aleksandrov
2019-07-30 11:23 ` Allan W. Nielsen
2019-07-30 10:04 ` Ido Schimmel
2019-07-30 12:19 ` Allan W. Nielsen
2019-07-30 14:34 ` Andrew Lunn
2019-07-30 19:00 ` Allan W. Nielsen
2019-07-31 3:31 ` Andrew Lunn
2019-07-31 8:01 ` Allan W. Nielsen
2019-07-31 13:45 ` Andrew Lunn
2019-07-31 19:38 ` Allan W. Nielsen
2019-08-01 14:22 ` Allan W. Nielsen
2019-07-26 13:46 ` Andrew Lunn
2019-07-26 19:50 ` Allan W. Nielsen
2019-07-27 3:02 ` Andrew Lunn
2019-07-28 19:15 ` Allan W. Nielsen
2019-07-28 23:07 ` Andrew Lunn
2019-07-29 6:09 ` Ido Schimmel
2019-07-29 12:43 ` Allan W. Nielsen
2019-08-01 19:17 ` Vivien Didelot
2019-08-01 19:48 ` Horatiu Vultur
2019-08-01 20:08 ` 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=20190729175136.GA28572@splinter \
--to=idosch@idosch.org \
--cc=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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).