Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3500699ybi; Mon, 29 Jul 2019 07:37:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqxIyGMub3NYsIMgQo6SrrqmXTPUmO8IaDhyZ1r6oDhhU/t2RjVNGMMLZKorKlpurH/ZHWrV X-Received: by 2002:a62:58c4:: with SMTP id m187mr36657629pfb.147.1564411042941; Mon, 29 Jul 2019 07:37:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564411042; cv=none; d=google.com; s=arc-20160816; b=anYx54Bm/v0HfdjcAp1Hw3yYrrNEndqL1o4RTESY93L4HaYkoqNCUckPIl1Xwrfr0T fFrucwmDqbmdgI+bzHHUnVaImc/9PkO3c9tuZ21snIT6Oq05+l4qNs7/mPQjZMXETp2e QYx83+PUeXTH6iYJoindb+Rt73I8yeXEY5MRqp2cnIoekEUyXVvo2KhUh84q5D9M9lHq 96FzefvJp8k+mf287Dz0vk1QACPZBX3oJJ4nRmW2nkG0NQ+5M1m4rGQWCigyA2qLvrxJ JufUKQj5M+hj55dF7VG3YHwyzWWymm76zGX5D+6TCWLgXeYiGnbLQ6cyfox/ivIDt2xp 3naA== 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=D8Jq3apj3DcQCCIUlGLaNRcHDMVJ8jU5JXEeHtYDxYE=; b=XqQOgy8hnVv/bg3cScKdoqebLamg/y5BdDeVrAQxuqZ8XQXywCGuNdC514G2YMexjh OrP242JyqgjCW6sgNMiapTIjQm/rS/4TUCN3LLNKKdl+xxYEOhKkz0lRwt+ozP6yrL9g NPA/bCEwLEXM6IyGrr+x+EPMDFaKsWvgbOtrketnhfj1dDT4rc3yW1jILX39wp4Z3Ioo xrObUk3COMKpLEcqgRZ07QZ51Ms3BwKhufpiRmD20NF7Vmo+aGhyCtMzUB+Wiqz2A130 xBc5bWlv2ba+XE+UFlzcU6lCBP+bDMFW66vPsJWI+jzRqSAjQ/PSUIuGYLbM3f2yJ96n 1C0Q== 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 y12si28650873pgg.585.2019.07.29.07.37.07; Mon, 29 Jul 2019 07:37:22 -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 S1728447AbfG2OfM (ORCPT + 99 others); Mon, 29 Jul 2019 10:35:12 -0400 Received: from esa6.microchip.iphmx.com ([216.71.154.253]:33507 "EHLO esa6.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727324AbfG2OfL (ORCPT ); Mon, 29 Jul 2019 10:35:11 -0400 Received-SPF: Pass (esa6.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=esa6.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 (esa6.microchip.iphmx.com: no sender authenticity information available from domain of postmaster@email.microchip.com) identity=helo; client-ip=198.175.253.82; receiver=esa6.microchip.iphmx.com; envelope-from="Allan.Nielsen@microchip.com"; x-sender="postmaster@email.microchip.com"; x-conformance=spf_only Authentication-Results: esa6.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: PvxHzyGMjwszKpUYApDD/v/JSkAUvEiJfnAnWccnM0ZPnZ8QcbwU7efZpX8HIZYIsrFxgmfpjU hBS2g0B29MVca5KPRZuOep1ROkpbsqcB6qy7ghXd75fMES9ulZmjR4TLLdhQ9TLlUHhHh+yuW3 nb0jC2PJLntUZ9EzdcSUbFIoDFI96JrD3jpFGcUAZb6GPmHqukCosyqrMCI9O5kD8HqsTRz5zh NVYa0v+XBL34PmZxzMkFGekYyx9nPB8/YUHejphmd/oaq4AOHqs7mNpHWM0+OqntROR3Hcy/VV 0oA= X-IronPort-AV: E=Sophos;i="5.64,323,1559545200"; d="scan'208";a="40097631" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Jul 2019 07:35:10 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex01.mchp-main.com (10.10.87.71) 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 07:35:09 -0700 Received: from localhost (10.10.85.251) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 29 Jul 2019 07:35:09 -0700 Date: Mon, 29 Jul 2019 16:35:09 +0200 From: "Allan W. Nielsen" To: Nikolay Aleksandrov CC: Horatiu Vultur , , , , , Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups Message-ID: <20190729143508.tcyebbvleppa242d@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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: 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 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. /Allan