Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4707096ybi; Tue, 30 Jul 2019 06:48:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqylbVfLxvG4sI/LLPMXXEHPlu3hPlF0OgvARLnFwYMIT8ZrozzuD+aS7AmITZWWTX8qNyie X-Received: by 2002:a62:58c4:: with SMTP id m187mr41619562pfb.147.1564494523696; Tue, 30 Jul 2019 06:48:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564494523; cv=none; d=google.com; s=arc-20160816; b=GLa7C5HKeC3g3IWZ8gvnOVi59QOX9vSu1+/qZuieeVXr4X0bHuq6oDTD23NtU/1xUM Pz7P/6CDNFxx4EyvrTagLok+yAjfHZlL93cHlvTA/0hXs4niayU7h7TtgoPaSwsK/yc3 tvlmbv/hdNju+9/ZhJx0J0bA8Q7zpXkO0EZkBLzy/A0gOnrZW0DLqw/Ox8KC8sh/zZYC 0lXk7VBBJ/IiK5oUrf0a9TTdruRoGyBjA6m0n+2Kz14+mL7rlE2HzxHCQW7iqfXzGRvJ XkWndNFkkjin9eeNoAS/FD9twRNDlxcGf5sadLiaXdgYtQKbkGQz4cjRGSOipF1J0cbO DU8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr; bh=NtFMQdRD65IaqtXA11y3dTG6HHvwTdFj6tUYJHwB28s=; b=X61FLBN0t6eXOJZ6L/pnWbOYkuNz6Md7vh7p8tb7vkH3Sck3Q8gX6JjwfN3PB32lkK OwGAg5sGwq6/wneL4q4Qivl1LN3EEB58hE7lqqBJU297eowxIyPphm6KNOavI+Or40OW jPDIjk28R4cpBSfvP+bdhiCNTb5Nxz+Q7nzkuIGKx1v1RSX8zJr/FI7lGzOLrz82HNmw 5w11o3T0W5NFMWGEGjpntGc6+3NbtSrGqtMSGxC9L40u4ZJz+5rtlpl1D3+z56SFp/gM D1GKHOS987Tv1F2W6uZ5sRtkNy4dWtoZBpll15XWR3/V1PpxETI5XK20H7wYzNWzAZSn ubQQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=microchip.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x66si20932631pfd.156.2019.07.30.06.48.29; Tue, 30 Jul 2019 06:48:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729018AbfG3G1Z (ORCPT + 99 others); Tue, 30 Jul 2019 02:27:25 -0400 Received: from esa4.microchip.iphmx.com ([68.232.154.123]:33527 "EHLO esa4.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728981AbfG3G1Z (ORCPT ); Tue, 30 Jul 2019 02:27:25 -0400 Received-SPF: Pass (esa4.microchip.iphmx.com: domain of Allan.Nielsen@microchip.com designates 198.175.253.82 as permitted sender) identity=mailfrom; client-ip=198.175.253.82; receiver=esa4.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="Allan.Nielsen@microchip.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 mx a:ushub1.microchip.com a:smtpout.microchip.com a:mx1.microchip.iphmx.com a:mx2.microchip.iphmx.com include:servers.mcsv.net include:mktomail.com include:spf.protection.outlook.com ~all" Received-SPF: None (esa4.microchip.iphmx.com: no sender authenticity information available from domain of postmaster@email.microchip.com) identity=helo; client-ip=198.175.253.82; receiver=esa4.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="postmaster@email.microchip.com"; x-conformance=spf_only Authentication-Results: esa4.microchip.iphmx.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=Allan.Nielsen@microchip.com; spf=None smtp.helo=postmaster@email.microchip.com; dmarc=pass (p=none dis=none) d=microchip.com IronPort-SDR: J0cATDpZs7qRKgH9tpimCyLWaFwhPVNUT87pe13JM204EJlK7fa9U14roaUwlzPyPnfbmDiA3C zOFyxfROpZcyfJEqO+BuEV62VtyYpFPMmRttElC+t4jpYwwXcyP2wQjI+cLu0rmoZ5PiT/MMbg KZ/20nF3B3dDMpFjv7hjZibyqOtlQFflpDnWJeV8u/KjrjzAzQxxSBGS2K01dacqGzrciSWzFU BcJ6zQFD3t1rmQscvog+mNlvG8BltCVusUKeMqdzo9cNiMYISTpnZm1eb8uDCgwosKqFcvIMvU FE0= X-IronPort-AV: E=Sophos;i="5.64,325,1559545200"; d="scan'208";a="42450189" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa4.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Jul 2019 23:27:24 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.85.151) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 29 Jul 2019 23:27:23 -0700 Received: from localhost (10.10.85.251) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 29 Jul 2019 23:27:23 -0700 Date: Tue, 30 Jul 2019 08:27:22 +0200 From: "Allan W. Nielsen" To: Ido Schimmel CC: Nikolay Aleksandrov , Horatiu Vultur , , , , , Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups Message-ID: <20190730062721.p4vrxo5sxbtulkrx@lx-anielsen.microsemi.net> References: <20190726120214.c26oj5vks7g5ntwu@soft-dev3.microsemi.net> <20190729121409.wa47uelw5f6l4vs4@lx-anielsen.microsemi.net> <95315f9e-0d31-2d34-ba50-11e1bbc1465c@cumulusnetworks.com> <20190729131420.tqukz55tz26jkg73@lx-anielsen.microsemi.net> <3cc69103-d194-2eca-e7dd-e2fa6a730223@cumulusnetworks.com> <20190729135205.oiuthcyesal4b4ct@lx-anielsen.microsemi.net> <20190729143508.tcyebbvleppa242d@lx-anielsen.microsemi.net> <20190729175136.GA28572@splinter> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20190729175136.GA28572@splinter> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The 07/29/2019 20:51, Ido Schimmel wrote: > 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. Yes. The thread is also a bit confusing because we half way through realized that we misunderstood how the multicast packets should be handled (sorry about that). To begin with we had a driver where multicast packets was only copied to the CPU if someone needed it. Andrew and Nikolay made us aware that this is not how other drivers are doing it, so we changed the driver to include the CPU in the default multicast flood-mask. This changes the objective a bit. To begin with we needed to get more packets to the CPU (which could have been done using tc ingress rules and a trap action). Now after we changed the driver, we realized that we need something to limit the flooding of certain L2 multicast packets. This is the new problem we are trying to solve! Example: Say we have a bridge with 4 slave interfaces, then we want to install a forwarding rule saying that packets to a given L2-multicast MAC address, should only be flooded to 2 of the 4 ports. (instead of adding rules to get certain packets to the CPU, we are now adding other rules to prevent other packets from going to the CPU and other ports where they are not needed/wanted). This is exactly the same thing as IGMP snooping does dynamically, but only for IP multicast. The "bridge mdb" allow users to manually/static add/del a port to a multicast group, but still it operates on IP multicast address (not L2 multicast addresses). > Nik suggested SIOCADDMULTI. It is not clear to me how this should be used to limit the flooding, maybe we can make some hacks, but as far as I understand the intend of this is maintain the list of addresses an interface should receive. I'm not sure this should influence how for forwarding decisions are being made. > and I suggested a tc filter to get the packet to the CPU. The TC solution is a good solution to the original problem where wanted to copy more frames to the CPU. But we were convinced that this is not the right approach, and that the CPU by default should receive all multicast packets, and we should instead try to find a way to limit the flooding of certain frames as an optimization. > 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 Yes. This can work in the SW bridge. > If you want to forward the packet in hardware and locally receive it, > you can chain several mirred action and then a trap action. I'm not I fully understand how this should be done, but it does sound like it becomes quite complicated. Also, as far as I understand it will mean that we will be using TCAM/ACL resources to do something that could have been done with a simple MAC entry. > Both options avoid HW egress ACLs which your design does not support. True, but what is wrong with expanding the functionality of the normal forwarding/MAC operations to allow multiple destinations? It is not an uncommon feature (I just browsed the manual of some common L2 switches and they all has this feature). It seems to fit nicely into the existing user-interface: bridge fdb add 01:21:6C:00:00:01 port eth0 bridge fdb append 01:21:6C:00:00:01 port eth1 It seems that it can be added to the existing implementation with out adding significant complexity. It will be easy to offload in HW. I do not believe that it will be a performance issue, if this is a concern then we may have to do a bit of benchmarking, or we can make it a configuration option. Long story short, we (Horatiu and I) learned a lot from the discussion here, and I think we should try do a new patch with the learning we got. Then it is easier to see what it actually means to the exiting code, complexity, exiting drivers, performance, default behavioral, backwards compatibly, and other valid concerns. If the patch is no good, and cannot be fixed, then we will go back and look further into alternative solutions. -- /Allan