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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 F35CAC43381 for ; Mon, 18 Jan 2021 19:02:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BED5920756 for ; Mon, 18 Jan 2021 19:02:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436947AbhARTCf (ORCPT ); Mon, 18 Jan 2021 14:02:35 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:46572 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407907AbhARTB4 (ORCPT ); Mon, 18 Jan 2021 14:01:56 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1l1Zm4-001KVu-BB; Mon, 18 Jan 2021 20:01:12 +0100 Date: Mon, 18 Jan 2021 20:01:12 +0100 From: Andrew Lunn To: Tobias Waldekranz Cc: Rasmus Villemoes , Network Development , Vivien Didelot , Horatiu Vultur , Vladimir Oltean Subject: Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports) Message-ID: References: <6106e3d5-31fc-388e-d4ac-c84ac0746a72@prevas.dk> <87h7nhlksr.fsf@waldekranz.com> <87v9bujdwm.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9bujdwm.fsf@waldekranz.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Jan 18, 2021 at 07:30:49PM +0100, Tobias Waldekranz wrote: > On Mon, Jan 18, 2021 at 18:50, Andrew Lunn wrote: > >> I suppose the real solution is having userspace do some "bridge mdb add" > >> yoga, but since no code currently uses > >> MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC_DA_MGMT, I don't think there's any > >> way to actually achieve this. And I have no idea how to represent the > >> requirement that "frames with this multicast DA are only to be directed > >> at the CPU" in a hardware-agnostic way. > > > > The switchdev interface for this exists, because there can be > > multicast listeners on the bridge. When they join a group, they ask > > the switch to put in a HOST MDB, which should cause the traffic for > > That is not quite the same thing as "management" though. Adding the > group to the host MDB will not allow it to pass through blocked (in the > STP sense) ports for example. With a management entry, the switch will > trap the packet with a TO_CPU tag, which means no ingress policy can get > in the way of it reaching the CPU. Ah, yes. I don't suppose the DA is part of the special group which the switch will recognise as management and pass it on? 01:80:c2:00:00:00 - 01:80:c2:00:00:07 01:80:c2:00:00:08 - 01:80:c2:00:00:0f 01:80:c2:00:00:20 - 01:80:c2:00:00:27 01:80:c2:00:00:28 - 01:80:c2:00:00:2f Andrew