From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E9C2C433FF for ; Mon, 29 Jul 2019 13:14:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 28E5F2070B for ; Mon, 29 Jul 2019 13:14:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728529AbfG2NOY (ORCPT ); Mon, 29 Jul 2019 09:14:24 -0400 Received: from esa6.microchip.iphmx.com ([216.71.154.253]:26607 "EHLO esa6.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728077AbfG2NOX (ORCPT ); Mon, 29 Jul 2019 09:14:23 -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: G261h5Die/W2fcW8zeh0Zu7Ii9AVIm1kAQOMRhWOK5J3lDD/pJ6IxazQ8p8uxsvDqrXXP8WprS XCyjsCUJWdTWsszgJnXB7DeC3SOdnkT5qjyHpdlfi5YsYzL6JQT3Obfho/CYio1gZ8xwl5Bq8W R5df9VOn4exDmTzj6Zky7GBqN+GJ+EpIiRG4NtyWyHS3wETZRQ6pXr9IH2DOg+mdMtehSPo2vP dielJvi78eXAjoMupqSCHYNIJToGxlwdnoCFbyMpIRVVwIv3JmCHzUSt2J8QXbyT65gChwsA3r Ioo= X-IronPort-AV: E=Sophos;i="5.64,322,1559545200"; d="scan'208";a="40086148" 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 06:14:22 -0700 Received: from chn-vm-ex03.mchp-main.com (10.10.87.152) by chn-vm-ex02.mchp-main.com (10.10.87.72) 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:14:21 -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:14:22 -0700 Date: Mon, 29 Jul 2019 15:14:21 +0200 From: "Allan W. Nielsen" To: Nikolay Aleksandrov CC: Horatiu Vultur , , , , , Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups Message-ID: <20190729131420.tqukz55tz26jkg73@lx-anielsen.microsemi.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <95315f9e-0d31-2d34-ba50-11e1bbc1465c@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:22, Nikolay Aleksandrov wrote: > 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. Here is my thinking (needs much more elaboration, which will come if we do a patch to test it out): In br_pkt_type Rename BR_PKT_MULTICAST to BR_PKT_MULTICAST_IP Add a new type called BR_PKT_MULTICAST_L2 In br_handle_frame_finish if (is_multicast_ether_addr(dest)) { /* by definition the broadcast is also a multicast address */ if (is_broadcast_ether_addr(dest)) { pkt_type = BR_PKT_BROADCAST; local_rcv = true; } else { pkt_type = BR_PKT_MULTICAST; if (br_multicast_rcv(br, p, skb, vid)) goto drop; } } Change the code above to detect if it is a BR_PKT_MULTICAST_IP or a BR_PKT_MULTICAST_L2 In this section: switch (pkt_type) { .... } if (dst) { } else { } Add awareness to the BR_PKT_MULTICAST_L2 type, and allow it do forwarding according to the static entry if it is there. > 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. Well, I wanted the SW bridge implementation to behave the same with an without HW offload. And also, I believe that is conceptually belongs to the MAC tables. /Allan