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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BA90DC4332F for ; Thu, 20 Oct 2022 14:24:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K5IzhstRtuNjFXWau6m0TcxTM7qHnAMXKhDtqs6d9ds=; b=ouOIg+tRxOGtfW /eIrdmzHmLhkjdn3MnVHQFRHz9K7YMBu1zWIsjlecuB7tFBj6GiWQVf3nbsxsAuM3G3WAY5zuY4P2 nX15kCRTQcd3srWVTWa4K5rPgWWDfHavUljh/+7hYhx7J+VvzsVKg4Z7EjWO41WAcGE9XIzznBIfY jLS7CXkXTzH+SDhIWowCWp8+zupG5/oOkkkPWCAN2PLAXerP9qu+8+lHfZgfxfPBxfyU7qY0iUA0a IKL0gP7k6NspK0HR7IHhqrB4mXId5395z5vE94vkxmhrxIcXpNi4bzG1HTEX98cPerbXXndRKlXB8 aQebj5Yv/wQ7ORawAhBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olWRh-00G4Wn-Pu; Thu, 20 Oct 2022 14:22:54 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olW9Y-00FrL5-Vv; Thu, 20 Oct 2022 14:04:10 +0000 Received: by mail-ej1-x62e.google.com with SMTP id k2so47689664ejr.2; Thu, 20 Oct 2022 07:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VcnoQx3qI7fpXJUKM0CZbdSa56iEX07NlfTNetUmqRw=; b=l5bu8brHSu0lV8jpdsslwekKWTitm3jcIzunKjSvYW6ZHEoyPulraEujek+0GP/Hvd VGynsaEV431/P0R4Up0JmdjgrLdZCAEXuS4thXeD1IkB0tL1c1TYwuHI0t7KEYQ28Ngi OjfuEUQIW5cD1w1T5Wl38wkB5vFtRrmJ1I+460JqsxkhwjNxe2MY/MZLUVaLfNXb9rxB mvWyTgjjiRaVTJ1C2POs4n/gmyaptI+zmwL5wEC99pA8loysp0dqVPy7tyoy7eWkwaRH 0PWHvnaY1M5vrwXfwri59mlcpsoC38vvExyhtVa9UiFedcueAmfgCoofwGx7+yQve6jp dbcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VcnoQx3qI7fpXJUKM0CZbdSa56iEX07NlfTNetUmqRw=; b=l68NezL2JAwdmPBDhqHivJ2k80Ub5jjYdiiTU3IN/0VE2rMzvYh1ZnN5vfzyE+tDAL GknvFRE9t2sfMEQk1bFZONxP9F+Dg71TJOzA5uCpzSV6CQg88dQkaxLc8m1u+SjUOcTE t0FZ+QvzOSUdbo3s/ornoLFAiQAgabrNllHNC84Gk7ZV/YpqfdzgP6+ViEUfOJI9lr1z KA3DO/R3QtpPI68vaEMMGy5l6HihhFoGixMCNOkO/knjpxBcmEs3jA6NFJdB7w9DfFCE +0ZKjp+U2GPx1okG/NIZwcW5FPJ6TJ303HXkRkEdjUrep0TFKO1H+13IevnQ40PK91rj Ht2Q== X-Gm-Message-State: ACrzQf2t6HD/eRYqigWGsV6ttDSUstEXOublEOrYbQZY6Z4TNyR5+1a8 WmyCVr4aWMmUHO1BoyUVqB4= X-Google-Smtp-Source: AMsMyM4SZEZSqVPTVYvWzQRYrzgh/kATVwZIqEmKTRuF0c5R/E5+UHJTLTdHcYlKatrB4zrmQDmY/g== X-Received: by 2002:a17:906:cc0b:b0:78e:1d51:36ea with SMTP id ml11-20020a170906cc0b00b0078e1d5136eamr11264073ejb.408.1666274645060; Thu, 20 Oct 2022 07:04:05 -0700 (PDT) Received: from skbuf ([188.27.184.197]) by smtp.gmail.com with ESMTPSA id nb36-20020a1709071ca400b0073ddb2eff27sm10450359ejc.167.2022.10.20.07.04.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Oct 2022 07:04:04 -0700 (PDT) Date: Thu, 20 Oct 2022 17:04:00 +0300 From: Vladimir Oltean To: Ido Schimmel Cc: "Hans J. Schultz" , davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vivien Didelot , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , UNGLinuxDriver@microchip.com, Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Russell King , Christian Marangi , Daniel Borkmann , Yuwei Wang , Petr Machata , Florent Fourcot , Hans Schultz , Joachim Wiberg , Amit Cohen , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v8 net-next 05/12] net: dsa: propagate the locked flag down through the DSA layer Message-ID: <20221020140400.h4czo4wwv7erncy7@skbuf> References: <20221018165619.134535-1-netdev@kapio-technology.com> <20221018165619.134535-1-netdev@kapio-technology.com> <20221018165619.134535-6-netdev@kapio-technology.com> <20221018165619.134535-6-netdev@kapio-technology.com> <20221020130224.6ralzvteoxfdwseb@skbuf> <20221020133506.76wroc7owpwjzrkg@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221020_070409_076105_DA29BE09 X-CRM114-Status: GOOD ( 32.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Oct 20, 2022 at 04:57:35PM +0300, Ido Schimmel wrote: > On Thu, Oct 20, 2022 at 04:35:06PM +0300, Vladimir Oltean wrote: > > On Thu, Oct 20, 2022 at 04:24:16PM +0300, Ido Schimmel wrote: > > > On Thu, Oct 20, 2022 at 04:02:24PM +0300, Vladimir Oltean wrote: > > > > On Tue, Oct 18, 2022 at 06:56:12PM +0200, Hans J. Schultz wrote: > > > > > @@ -3315,6 +3316,7 @@ static int dsa_slave_fdb_event(struct net_device *dev, > > > > > struct dsa_port *dp = dsa_slave_to_port(dev); > > > > > bool host_addr = fdb_info->is_local; > > > > > struct dsa_switch *ds = dp->ds; > > > > > + u16 fdb_flags = 0; > > > > > > > > > > if (ctx && ctx != dp) > > > > > return 0; > > > > > @@ -3361,6 +3363,9 @@ static int dsa_slave_fdb_event(struct net_device *dev, > > > > > orig_dev->name, fdb_info->addr, fdb_info->vid, > > > > > host_addr ? " as host address" : ""); > > > > > > > > > > + if (fdb_info->locked) > > > > > + fdb_flags |= DSA_FDB_FLAG_LOCKED; > > > > > > > > This is the bridge->driver direction. In which of the changes up until > > > > now/through which mechanism will the bridge emit a > > > > SWITCHDEV_FDB_ADD_TO_DEVICE with fdb_info->locked = true? > > > > > > I believe it can happen in the following call chain: > > > > > > br_handle_frame_finish > > > br_fdb_update // p->flags & BR_PORT_MAB > > > fdb_notify > > > br_switchdev_fdb_notify > > > > > > This can happen with Spectrum when a packet ingresses via a locked port > > > and incurs an FDB miss in hardware. The packet will be trapped and > > > injected to the Rx path where it should invoke the above call chain. > > > > Ah, so this is the case which in mv88e6xxx would generate an ATU > > violation interrupt; in the Spectrum case it generates a special packet. > > Not sure what you mean by "special" :) It's simply the packet that > incurred the FDB miss on the SMAC. > > > Right now this packet isn't generated, right? > > Right. We don't support BR_PORT_LOCKED so these checks are not currently > enabled in hardware. To be clear, only packets received via locked ports > are able to trigger the check. > > > > > I think we have the same thing in ocelot, a port can be configured to > > send "learn frames" to the CPU. > > > > Should these packets be injected into the bridge RX path in the first > > place? They reach the CPU because of an FDB miss, not because the CPU > > was the intended destination. > > The reason to inject them to the Rx path is so that they will trigger > the creation of the "locked" entry in the bridge driver (when MAB is > on), thereby notifying user space about the presence of a new MAC behind > the locked port. We can try to parse them in the driver and notify the > bridge driver via SWITCHDEV_FDB_ADD_TO_BRIDGE, but it's quite ugly... "ugly" => your words, not mine... But abstracting things a bit, doing what you just said (SWITCHDEV_FDB_ADD_TO_BRIDGE) for learn frames would be exactly the same thing as what mv88e6xxx is doing (so your "ugly" comment equally applies to Marvell). The learn frames are "special" in the sense that they don't belong to the data path of the software bridge*, they are just hardware specific information which the driver must deal with, using a channel that happens to be Ethernet and not an IRQ/MDIO. *in other words, a bridge with proper RX filtering should not even receive these frames, or would need special casing for BR_PORT_MAB to not drop them in the first place. I would incline towards an unified approach for CPU assisted learning, regardless of this (minor, IMO) difference between Marvell and other vendors. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel