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 BE840C76196 for ; Tue, 28 Mar 2023 11:50:39 +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=LTvBsAMYEFQayadSTahYC92hYzIB3z24gQIBOC5/ygo=; b=2h5Fcak/uVHW8F 4ANDJ1k9zv7l9Uwk95i2fOFi+o3UAY/ewvNKZ1Gsw8oEA5xSiVlzx90u/RpNLGxdTfDE+18Pgo4/i /A/ZSrOskXYAybw4ygriMeTBK9bxA29261P1yQr+GsAAdyYgdYGHK82DGpXpla1LM0AYbgDm633OG iKue3UI7rjsh8qnZLPoJBpyws1c9bKmzIgswofT6WwZCiNf1dM/ppCzLYAlfM7tn645s2M8EKAru6 wPi3hMP2dRRhqHZfAJaqF25SqJ2oPn5H8oM9BEuJSjENvEaSRrRz+D6oZQBMp2/MHN8mI8ZA9Kl12 MyC499O4f3LqAOPOO8Lw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ph7po-00EDmK-1S; Tue, 28 Mar 2023 11:49:52 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ph7pk-00EDkn-2Y; Tue, 28 Mar 2023 11:49:50 +0000 Received: by mail-wm1-x332.google.com with SMTP id o24-20020a05600c511800b003ef59905f26so7207086wms.2; Tue, 28 Mar 2023 04:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680004187; 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=d/r365YzR4z2GUjbK/bi1SZFXqHlnLKc6PIvPNZ2lRc=; b=iO58f6tcmkzPWSbg7kupiEHtiApSvwACv57rpe3rm8RiJ8ouJG59UwXU2DToee2okr IUcYWKye6jJmJYfvu8eeByd1gtdC96vRX3/BCxhGs4KBB4vGDv0S0sCZHvk0eYBn69ov DcIjL4WpuncS0QlGPlBdg+C1Br3J70PkHveOmrnjimVIIMLw9HqmvqulopAjRdWAmEza AyVJoxGQYq5mBYBpvZVkYVsLfS8aBpjvkPZanvSjSmzb6xDTVCLb1so2EId6nM29koss 74FFqqK2KtSZzXaFwagq5m/p/yrL+kpn7s0ykdfZInmR9zV5ehKdmn0DDBgYgvfVxhbf V/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680004187; 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=d/r365YzR4z2GUjbK/bi1SZFXqHlnLKc6PIvPNZ2lRc=; b=PaolrkWekcR9ezG+EP+hYH0VNLbl45ZhAF0OqNa94IFhP1Z5hLtcikcOSBl5Z56knP LNR0tkgdZ5tlykyCE0qBvqTlAgJEsEBLIGb9XBOFtcdI01I8IG8gfqugIegpEOcv7nQx +mnY2oLgfhpspQkjp5YKnFDCtC8ZqVomJuERYEcoSfrmluLp27fnM6fA82MD61S05olY WYOQjqfFCP5a3mvYgRBNti1OhpyICdte4CUzsOVO6+e0XOsDxnjhdb5BpfWQbD9a2yTp Obrn8vz9Ih0/FtuwmwWh3/OBntToNaUlxjlk476qZchz7khho/om5ro4blBPwuaD8lia mItQ== X-Gm-Message-State: AO0yUKWLCNCkqd/fvTtlEP60QizlzVgb2dwbcmLRBEc7dDWqm21Hda7W aDplkwAs+y1Wy/AMQwyQKUM= X-Google-Smtp-Source: AK7set+zTszhDgDoSbIPu4QLbK7SYfkBZiuqVsVMkXIAf2QkJVEAEbWd1vEqziskOOvC8WeShKxd4A== X-Received: by 2002:a05:600c:3795:b0:3ed:a82d:dffb with SMTP id o21-20020a05600c379500b003eda82ddffbmr11330072wmr.40.1680004187137; Tue, 28 Mar 2023 04:49:47 -0700 (PDT) Received: from skbuf ([188.27.184.189]) by smtp.gmail.com with ESMTPSA id u15-20020a05600c210f00b003ed2433aa4asm17097652wml.41.2023.03.28.04.49.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 04:49:46 -0700 (PDT) Date: Tue, 28 Mar 2023 14:49:43 +0300 From: Vladimir Oltean To: Hans Schultz Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , "maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER" , Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , AngeloGioacchino Del Regno , Claudiu Manoil , Alexandre Belloni , =?utf-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Christian Marangi , Ido Schimmel , open list , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" , "open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER" , "moderated list:ETHERNET BRIDGE" , "open list:KERNEL SELFTEST FRAMEWORK" Subject: Re: [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers Message-ID: <20230328114943.4mibmn2icutcio4m@skbuf> References: <20230318141010.513424-1-netdev@kapio-technology.com> <20230318141010.513424-3-netdev@kapio-technology.com> <20230327115206.jk5q5l753aoelwus@skbuf> <87355qb48h.fsf@kapio-technology.com> <20230327160009.bdswnalizdv2u77z@skbuf> <87pm8tooe1.fsf@kapio-technology.com> <20230327225933.plm5raegywbe7g2a@skbuf> <87ileljfwo.fsf@kapio-technology.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87ileljfwo.fsf@kapio-technology.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230328_044948_843951_9559C1D9 X-CRM114-Status: GOOD ( 24.12 ) 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 Tue, Mar 28, 2023 at 01:04:23PM +0200, Hans Schultz wrote: > On Tue, Mar 28, 2023 at 01:59, Vladimir Oltean wrote: > > > > which idea is that, again? > > So I cannot us the offloaded flag as it is added by DSA in the common > case when using 'bridge fdb replace ... dynamic'. Why not? I find it reasonable that the software bridge does not age out a dynamic FDB entry that is offloaded to hardware... the hardware should do that ("dynamic" being the key). At least, I find it more reasonable than the current behavior, where the bridge notifies dynamic FDB entries to switchdev, but doesn't say they're dynamic, and switchdev treats them as static, so they don't roam from one bridge port to another until software sees a packet with that MAC DA, and they have the potential of blocking traffic because of that. If for some reason you do think that behavior is useful and still want to keep it (I'm not sure I would), I would consider extending struct switchdev_notifier_fdb_info with a "bool pls_dont_age_out", and I would make dsa_fdb_offload_notify() set this to true if the driver did actually install the dynamic FDB entry as dynamic in the ATU. > > The idea is then to use the ext_learn flag instead, which is not aged by > the bridge. To do this the driver (mv88e6xxx) will send a > SWITCHDEV_FDB_ADD_TO_BRIDGE switchdev event when the new dynamic flag is > true. The function sending this event will then be named > mv88e6xxx_add_fdb_synth_learned() in > drivers/net/dsa/mv88e6xxx/switchdev.c, replacing the > mv88e6xxx_set_fdb_offloaded() function but in most part the same > content, just another event type. Basically you're suggesting that the hardware driver, after receiving a SWITCHDEV_FDB_ADD_TO_DEVICE and responding to it with SWITCHDEV_FDB_OFFLOADED, emits a SWITCHDEV_FDB_ADD_TO_BRIDGE which takes over that software bridge FDB entry, with the advantage that the new one already has the semantics of not being aged out by the software bridge. hmmm... I'd say that the flow should work even with a single notifier emitted from the driver side, which would be SWITCHDEV_FDB_OFFLOADED, perhaps annotated with some qualifiers that would inform the bridge a certain behavior is required. Although, as mentioned, I think that in principle, "pls_dont_age_out" should be unnecessary, because it just papers over the issue that switchdev drivers treat static and dynamic FDB entries just the same, and "pls_dont_age_out" would be the differentiator for an issue that should have been solved elsewhere, as it could lead to other problems of its own. Basically we're designing around a workaround to a problem to which we're turning a blind eye. These are my 2c. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel