Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3664944ybi; Mon, 29 Jul 2019 10:22:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxv7hjfqp2ehKw+QDIoiBzBvMkY93hqNwRucRYi02zrugOYMck8pz6U873DzgOpvXTIgeG X-Received: by 2002:a17:90a:1ae1:: with SMTP id p88mr12874896pjp.26.1564420937971; Mon, 29 Jul 2019 10:22:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564420937; cv=none; d=google.com; s=arc-20160816; b=XKTZAOb3fKI4qGruEPrS4qSe1NeF4obODg4lhIjS+mb+FA6xEFuGsl66eefZMTmID+ /yrq46ucrv4/Zp41tbitVvWlwpGHKvpovxizGn9/PJF/L57f68FjROn/T9HauE0so9t+ 840yOgwrHc8n+9WBpeIg2HdrYldI3AQRVVKIVEFcdfa2qLoGL/WO61r0q4f3Rd2D/Kke NltxfxC4hA7Q8l3CPdTX2b7g8bvaTpQ47mS/GBn82MbxwDR1b6sjlnLPiG5IbRCiTxTQ tO0V4d3CUhIX4z/E/3pfKgbt7HpyhoTArmVW6jKD5eFxYg/tsggAqzitiN2HLdjkTtpN 9WRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dkim-signature; bh=FaAv73c7/caKA+SdXX+K+mh6Cm/86re9CSFJB7tkoPQ=; b=GTdINDoCUdKZ/MzhKzF6vWZBopFq65+6wJMcH9XknYpsIBQqT5IPJucHhvWbofES+0 m5QySaaG7xz2YjcFiThx8JI0gmb4tszwgsdPdbs9fMdQp/Wg5+m9e5mJv+hsNElhKWoF wBLiM5bUADJFbs2hU1/+0ibGsXZjB8PTD+cHREJaQNl02B2NmRgbnjM3qiSX1H417AQA BWJNlUjCHjw6WhcOZ69E4JNLLhXQVTQgnsX1eboLSrQ+HocVoFH+9J9uBAUUjSlFqdR1 7zM8XM0VY5VKlaJGo0iJUzAoWfJ2ULSyLF0y4Rq4nkcejZj6CWDO5qMPZlagU/ZLsbY0 yuEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cumulusnetworks.com header.s=google header.b=KW0x3QFg; 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=pass (p=NONE sp=NONE dis=NONE) header.from=cumulusnetworks.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id co4si7442015plb.363.2019.07.29.10.22.02; Mon, 29 Jul 2019 10:22:17 -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; dkim=pass header.i=@cumulusnetworks.com header.s=google header.b=KW0x3QFg; 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=pass (p=NONE sp=NONE dis=NONE) header.from=cumulusnetworks.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728423AbfG2MuX (ORCPT + 99 others); Mon, 29 Jul 2019 08:50:23 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:34045 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726748AbfG2MuW (ORCPT ); Mon, 29 Jul 2019 08:50:22 -0400 Received: by mail-wr1-f66.google.com with SMTP id 31so61760013wrm.1 for ; Mon, 29 Jul 2019 05:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FaAv73c7/caKA+SdXX+K+mh6Cm/86re9CSFJB7tkoPQ=; b=KW0x3QFgAkbJtmPiI15VrDGcIK27GRcEgALtT7jEwcEraGN0NVvEz0pwJrsydt95ER Gscowby0iaA/F56RCBP3ZeYqmxbBk0IT8HWNux4xxYpbZXYyoOy5qSmYe11ZL7x4A70k GOuwSowPaBiPvlK5jU1gZjN8I57ndtLQhpu2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FaAv73c7/caKA+SdXX+K+mh6Cm/86re9CSFJB7tkoPQ=; b=Rd0loNjJYxd4Nn0f/EbR74AsRfkL9I8NtoeyZw/Rtfg97PXtEuUd7cmVySLIYkBF1+ Q6WDnHoT3YZ5uulFXihsR+cDg6zkbyTn5Cv8iXqammirVhuXq9mCHc2f/JtdULSbTIpF Oh1zyffBTbcD8WCvtTPd1SOqVf2TFCc0ZNcqBX5Jk7sevM9e4olsOmdigiWbqB3CrGPM j5ikZE2dMnNmoMcUo+3j6qSqQMkPzfcZu9WA1y/pu/fM7XhHoYoMY0yvQwi28N41qRLt onJqtw8wO0Y3ZPdVMO4O2N8dzrMkwCNPz27DysIyTUohFvyVODrYOfwX61msE3eCS3aK 671Q== X-Gm-Message-State: APjAAAU7AA/VzdBfRTE8GEi8XqAjqo6eKNXiDh+EAoElmH8IPfFhuIsC hSXS3DorcYVhhPY2Zp0Vk8a++NBats0= X-Received: by 2002:a5d:6a52:: with SMTP id t18mr19177948wrw.178.1564404620043; Mon, 29 Jul 2019 05:50:20 -0700 (PDT) Received: from [192.168.0.107] (84-238-136-197.ip.btc-net.bg. [84.238.136.197]) by smtp.gmail.com with ESMTPSA id a67sm67519549wmh.40.2019.07.29.05.50.18 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 05:50:19 -0700 (PDT) Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups From: Nikolay Aleksandrov To: "Allan W. Nielsen" Cc: Horatiu Vultur , roopa@cumulusnetworks.com, davem@davemloft.net, bridge@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <1564055044-27593-1-git-send-email-horatiu.vultur@microchip.com> <7e7a7015-6072-d884-b2ba-0a51177245ab@cumulusnetworks.com> <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> Message-ID: Date: Mon, 29 Jul 2019 15:50:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <95315f9e-0d31-2d34-ba50-11e1bbc1465c@cumulusnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/07/2019 15:22, Nikolay Aleksandrov wrote: > Hi Allan, > On 29/07/2019 15:14, Allan W. Nielsen wrote: >> Hi Nikolay, >> >> 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 ? 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'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. >> On 25/07/2019 16:06, Nikolay Aleksandrov wrote: >>>>>>>>> In general NLM_F_APPEND is only used in vxlan, the bridge does not >>>>>>>>> handle that flag at all. FDB is only for *unicast*, nothing is joined >>>>>>>>> and no multicast should be used with fdbs. MDB is used for multicast >>>>>>>>> handling, but both of these are used for forwarding. >> This is true, and this should have been addressed in the patch, we were too >> focused on setting up the offload patch in the driver, and forgot to do the SW >> implementation. >> >> Do you see any issues in supporting this flag, and updating the SW >> forwarding in br_handle_frame_finish such that it can support/allow a FDB entry >> to be a multicast? >> > > 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. 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. > >> /Allan >> >