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 F07A7C4332F for ; Fri, 21 Oct 2022 11:23:28 +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=lxKgI+RRwlDaRpuWmCzqDCeBdOsSfwwAyqKpRiPiwkg=; b=MLiUogmicFhAyF uQKcXmmOwn2S1NUEtoXDDJWT0HVSRwfzkliEAM4kDFqHn2GCNmD8jRqVMTrPvaxfg4VtnDAYMfWnf SlNw7ytFND2gqvtdOxe6Jq6BvxZFJ/1Pi8Db+UF+WMaKK46AurLjnnHXz06ewrbHcqfAcEksxbfdu t/c3CndCf9Tc9rqYjDgTf+x7dJwIM+6QKaWUdHIhMq0Bj/aPZiAKklsz0D43l6EocvxDZDXiYWAdh P0hScU1Qw2oX3o+LmjR3pM27oLS99lnQQab0adMyjHeTz+pGgP8PL1548zDi9Y1D5HkBKlkkLFg9H 1C/0s9zQoPnkHJV59V6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olq6b-007M4w-Ha; Fri, 21 Oct 2022 11:22:25 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olq6Y-007M3Z-4s; Fri, 21 Oct 2022 11:22:23 +0000 Received: by mail-ed1-x529.google.com with SMTP id l22so4571606edj.5; Fri, 21 Oct 2022 04:22:21 -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=y83I/EEj5O1WzvhlqMvy69bC2C3kma+TguYlktElg+U=; b=aqI400aFX+Hv1if94yQ/9coImAcoL5xm5EE9Z8Pnq+JQ7MqId0ZuB5eW9kjAqCiUrN KMZPlHItsw5EctvNgdlnTcP5laLuqUz+SV1o33najcKCsjf0QARB5ow9Z44sTZTOmSeg UrpNC6fH6ciHR2X4rGmdJWOSbH4r9VMHXzYepV/zYSLDnnNwqU+kf3Zv2sg7HE61xVNl 7t3a9w2kLyvF5PibwmB0qSxZXtgVyxt+2/Ir7YJLUZG06dtskhoVW5tz2mc4jA71zIm4 UhnubOmNzJl78yCv0QqxYV7AfFoBR+16JycwYyxr/dmdd6j59K4vgycD/Tzgpk9gib2d VCVw== 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=y83I/EEj5O1WzvhlqMvy69bC2C3kma+TguYlktElg+U=; b=kT/N5PP4FezPHh2H2/4EVUNwPwd/ef4EGm1cBgM7++eh1CROcYAeI9cwWkpYu7jKTk gyPP0p5pI6HWlpdCHLJpFGt5MfPpyTW8s8Ta5Gl1+BdsfcaaA3DTe8PCCYnz53w5sCrj ELRZoIKsUof5QxE4saEFzISVId3oz9B/agcpYctCNBhPV9faTcjWihir/If7sbMOeAZw 2dKaKZUMr1RgHnt+F9ttwNrEPvVrdabD8Ny5Sa7fNgeac5cNkz70zpu1dkVxUIUL+HLI hMAh2T/uywyJ0ZWSMHmjBAsAqVUT9QopJsfSHakMt5rWF75FZ1bT2d/V+K2PcyYdzrD9 xCuw== X-Gm-Message-State: ACrzQf0JiHlysWyXomwxuhPICPbbulHG0Jcn24SBOh7BC39L49LfrMuS OuzB+FQC2hpZe0SIOtOePpA= X-Google-Smtp-Source: AMsMyM4Ljgcs84MFVGjjaNn1SINn2K1OMLuiOgFc7iq4/CDwKUIaipwaA3YvQFgGhkmQ345GuQJlMw== X-Received: by 2002:a17:906:db0e:b0:77b:82cf:54a6 with SMTP id xj14-20020a170906db0e00b0077b82cf54a6mr14838182ejb.691.1666351340215; Fri, 21 Oct 2022 04:22:20 -0700 (PDT) Received: from skbuf ([188.27.184.197]) by smtp.gmail.com with ESMTPSA id g22-20020a50d5d6000000b00457160c3c77sm13487340edj.20.2022.10.21.04.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Oct 2022 04:22:19 -0700 (PDT) Date: Fri, 21 Oct 2022 14:22:16 +0300 From: Vladimir Oltean To: netdev@kapio-technology.com Cc: 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 , Ido Schimmel , 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 10/12] net: dsa: mv88e6xxx: mac-auth/MAB implementation Message-ID: <20221021112216.6bw6sjrieh2znlti@skbuf> References: <20221018165619.134535-1-netdev@kapio-technology.com> <20221018165619.134535-1-netdev@kapio-technology.com> <20221018165619.134535-11-netdev@kapio-technology.com> <20221018165619.134535-11-netdev@kapio-technology.com> <20221020132538.reirrskemcjwih2m@skbuf> <2565c09bb95d69142522c3c3bcaa599e@kapio-technology.com> <20221020225719.l5iw6vndmm7gvjo3@skbuf> <82d23b100b8d2c9e4647b8a134d5cbbf@kapio-technology.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <82d23b100b8d2c9e4647b8a134d5cbbf@kapio-technology.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221021_042222_205277_E026AC64 X-CRM114-Status: GOOD ( 24.46 ) 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 Fri, Oct 21, 2022 at 08:47:42AM +0200, netdev@kapio-technology.com wrote: > On 2022-10-21 00:57, Vladimir Oltean wrote: > > On Thu, Oct 20, 2022 at 10:20:50PM +0200, netdev@kapio-technology.com > > wrote: > > > In general locked ports block traffic from a host based on if there > > > is a > > > FDB entry or not. In the non-offloaded case, there is only CPU > > > assisted > > > learning, so the normal learning mechanism has to be disabled as any > > > learned entry will open the port for the learned MAC,vlan. > > > > Does it have to be that way? Why can't BR_LEARNING on a BR_PORT_LOCKED > > cause the learned FDB entries to have BR_FDB_LOCKED, and everything > > would be ok in that case (the port will not be opened for the learned > > MAC/VLAN)? > > I suppose you are right that basing it solely on BR_FDB_LOCKED is possible. > > The question is then maybe if the common case where you don't need learned > entries for the scheme to work, e.g. with EAPOL link local packets, requires > less CPU load to work and is cleaner than if using BR_FDB_LOCKED entries? I suppose the real question is what does the bridge currently do with BR_LEARNING + BR_PORT_LOCKED, and if that is sane and useful in any case? It isn't a configuration that's rejected, for sure. The configuration could be rejected via a bug fix patch, then in net-next it could be made to learn these addresses with the BR_FDB_LOCKED flag. To your question regarding the common case (no MAB): that can be supported just fine when BR_LEARNING is off and BR_PORT_LOCKED is on, no? No BR_FDB_LOCKED entries will be learned. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel