Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3486136ybi; Mon, 29 Jul 2019 07:23:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqxV/gGjLIuI0GfuQmnogU/DRMv5++0oMREZoc79L3/+cV2ylT7maBTyebmiz77nZPQ4hx/E X-Received: by 2002:a63:69c1:: with SMTP id e184mr100760436pgc.198.1564410207812; Mon, 29 Jul 2019 07:23:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564410207; cv=none; d=google.com; s=arc-20160816; b=bVPoqm8DxnQ0g0X5JWryXIlRYL8uOeK9CISxTzoq9BBlYNdL6A3qvoPRW+lX7LL2/f OeYWimuEVRkPIoWX2KwvoNN2ucBLspTOIBr54tXx4Q0bRqNCztRergo3Et8C22jXxfDo vXn4k19K1jThmdT4wCcM3xCwfINpfA8tFnZqm3FvyxGGb6JftH9xUO4Be9uqj+U8ADly WnnjazfBKP0nt2pzuGj+r8dUKNsO+4nXqLogLXVMkRksIka7rqS7n3X+Tjeu+OhhUUKm t5FptuGh5vqPBcH35+EZB/7sJqXk9LEdTWGo7E9MCovqnI6wJR+inU0sfq4kumB4TbS+ Lo0Q== 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=Ht1a6hE+i0mqTWCStLZgOahcydF7YxuaJGpxiXoBrvo=; b=CaeZLZst8kJoSdA+wjYIhpdo2veCLf3KFZAmPq9qr98aaWvYCEo/CWH5xrjuvg672H zL3ELt6VRJm8V7uEPgcbiYswrVodzKvl5HeSyHGKDpD9HhXhBshNHoUwArO0QMUB54wy dgFAAso/DxL/VpDJZRcY//d8eZTeolmqVUiNrNAe6r1CBDol5jAsYTUKF8CNTdChS6SE lT5btIp/UKnz6EWZQ6HUaa2zP6pGDArG0NxZzEz+FezgRYIRRMxS3cn7N3kFTbvSqDKb cCvP2Jsgjix4LLe7dSv6n0m3wMpIisCriiPP9wwGrpetmhj07gkL7VhsvtPsiA61r2Aj tGLQ== 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 k190si27293440pgd.212.2019.07.29.07.23.11; Mon, 29 Jul 2019 07:23:27 -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 S1727601AbfG2NwJ (ORCPT + 99 others); Mon, 29 Jul 2019 09:52:09 -0400 Received: from esa5.microchip.iphmx.com ([216.71.150.166]:17927 "EHLO esa5.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726281AbfG2NwI (ORCPT ); Mon, 29 Jul 2019 09:52:08 -0400 Received-SPF: Pass (esa5.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=esa5.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 (esa5.microchip.iphmx.com: no sender authenticity information available from domain of postmaster@email.microchip.com) identity=helo; client-ip=198.175.253.82; receiver=esa5.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="postmaster@email.microchip.com"; x-conformance=spf_only Authentication-Results: esa5.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: Q2m3xpDPgjjxj23DYoeUpZ4quvmA8ESbiWJQs2VDQYn1U0RGudOEp+0oFH/bzu2W5UhZHlx9kQ TEQ3kq1AxAa9ASwgJ8ql9rrzk3HEyao1aGhqxDYdjEQ3JYUXXroE3JPSOG73aVW31JCixXnAWK U7M2NC2dDw3crndKHrSNMc6Vc74OMiWUeml1NVJNEIf606zx/CbEyGOdcKaLeiRAGZBKTRP0N7 aGOTojYeGg47Pum0d+gSyWHCBPjbX79Nh2sk6idKAiwfxNKSAibeHrF2E/ANrmbcX/LdcgyAOr +iE= X-IronPort-AV: E=Sophos;i="5.64,322,1559545200"; d="scan'208";a="41516577" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa5.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Jul 2019 06:52:07 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.87.152) by chn-vm-ex04.mchp-main.com (10.10.87.151) 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 06:52:07 -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 06:52:07 -0700 Date: Mon, 29 Jul 2019 15:52:06 +0200 From: "Allan W. Nielsen" To: Nikolay Aleksandrov CC: Horatiu Vultur , , , , , Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups Message-ID: <20190729135205.oiuthcyesal4b4ct@lx-anielsen.microsemi.net> References: <20190725142101.65tusauc6fzxb2yp@soft-dev3.microsemi.net> <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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <3cc69103-d194-2eca-e7dd-e2fa6a730223@cumulusnetworks.com> 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 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). > I'm sorry but that doesn't sound good to me for a case which is very rare and > there are existing ways to solve without incurring performance hits or increasing > code complexity. I do not consider it rarely, controling the forwarding of L2 multicast frames is quite common in the applications we are doing. > If you find a way to achieve this without incurring a performance hit or significant > code complexity increase, and without breaking current use-cases (e.g. unexpected default > forwarding behaviour changes) then please send a patch and we can discuss it further with > all details present. People have provided enough alternatives which avoid all of the > problems. Will do, thanks for the guidance. /Allan