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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43009C6FD1D for ; Tue, 21 Mar 2023 19:03:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229767AbjCUTDA (ORCPT ); Tue, 21 Mar 2023 15:03:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229663AbjCUTC7 (ORCPT ); Tue, 21 Mar 2023 15:02:59 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7A6751C87 for ; Tue, 21 Mar 2023 12:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=wQOGZW0XRxg9zqRtPqOD9ZPLKxGCemryNCznxBTEgkU=; b=4KZeaLC3aD3I2CF1W66hcmrwRU tXv4ZKF5+tHLq/JgqXi1SuCW9yCj5W+sxuuXbozUA0cL0xCBI2gAzBcM5duSUSKvMr504kaSnqigI 1pwPT1jhDLcOHQFjFJk7wc0aX2HaOmVTmP0kK7on5KUhOZQwyjGH3nLGUqK7Ad83DTDw=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pehFG-007zjy-EI; Tue, 21 Mar 2023 20:02:06 +0100 Date: Tue, 21 Mar 2023 20:02:06 +0100 From: Andrew Lunn To: Vladimir Oltean Cc: Jan Hoffmann , =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= , netdev@vger.kernel.org, Florian Fainelli , openwrt-devel@lists.openwrt.org, Sander Vanheule , erkin.bozoglu@xeront.com Subject: Re: [PATCH 0/6] realtek: fix management of mdb entries Message-ID: References: <20230303214846.410414-1-jan@3e8.eu> <20230306134636.p2ufzoqk6kf3hu3y@skbuf> <20230321172415.3ccdi4j226d5qa7h@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230321172415.3ccdi4j226d5qa7h@skbuf> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > If the DSA subsystem could handle the "merging" instead and also call > > port_mdb_add/port_mdb_del as appropriate for multicast router ports, the > > individual drivers wouldn't have to deal with this particular issue at all. > > > > > As a way to fix a bug quickly and get correct behavior, I guess there's > > > also the option of stopping to process multicast packets in hardware, > > > and configure the switch to always send any multicast to the CPU port > > > only. As long as the tagger knows to leave skb->offload_fwd_mark unset, > > > the bridge driver should know how to deal with those packets in > > > software, and forward them only to whom is interested. But the drawback > > > is that there is no forwarding acceleration involved. Maybe DSA should > > > have done that from the get go for drivers which didn't care about > > > multicast in particular, instead of ending up with this current situation > > > which appears to be slightly chaotic. > > > > Thanks, > > Jan > > Andrew, Florian, do you have any additional comments here? I've no real experience with this either. But it sounds like this merging should be pulled up into the bridge, if all switchdev drivers need it. Andrew