From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3C22A4018A DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4DF694014D 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== Date: Tue, 28 Mar 2023 14:49:43 +0300 From: Vladimir Oltean 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ileljfwo.fsf@kapio-technology.com> Subject: Re: [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans Schultz Cc: Andrew Lunn , Alexandre Belloni , Nikolay Aleksandrov , Kurt Kanzenbach , Eric Dumazet , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , Ivan Vecera , Florian Fainelli , Ido Schimmel , "moderated list:ETHERNET BRIDGE" , Roopa Prabhu , kuba@kernel.org, Paolo Abeni , =?utf-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= , Christian Marangi , Woojung Huh , Landen Chao , Jiri Pirko , Hauke Mehrtens , Sean Wang , DENG Qingfang , Claudiu Manoil , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , "moderated list:ARM/Mediatek SoC support" , AngeloGioacchino Del Regno , netdev@vger.kernel.org, open list , "maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER" , "open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER" , davem@davemloft.net 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. 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 72D92C76195 for ; Tue, 28 Mar 2023 11:49:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232921AbjC1Ltu (ORCPT ); Tue, 28 Mar 2023 07:49:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230073AbjC1Ltt (ORCPT ); Tue, 28 Mar 2023 07:49:49 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C816B4EE7; Tue, 28 Mar 2023 04:49:48 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id m6-20020a05600c3b0600b003ee6e324b19so7242338wms.1; 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=mwaZyL++Geww5Rz2Lr6auJGQ25OFGJGw4KPJNMT0qzMYoToajQ6EJ2XknNOvO84b06 xtx8SarV7J1ZkZofDttShQxp+vc9abMIUK4rbFHHmzFs4hSXLNjhUkAg830hGqojqkoZ aBusgX8SZj4EMDZyXQOMXMw62+IraAcAee+3xzK5q9KA8pdlxGsxiZYmKjyYOqWxdLpb FK8f5XFYr38Eo0gdWbW54gzesNehVMaaLu8n8IQfU/mX/nYTcXVRBRkxZdsZgVoL62RP d0YmlV6STgSCUzcl4WIz08TafQupLn+PHRn54H8N1RNhrVWsK5+H5ipK68ecmHUFk1h0 b9Og== X-Gm-Message-State: AO0yUKURt9aipupSx6KEiZSMZjvnw6ApgwG94O3/B9XxigQ+woiiUQnI ObpiIKMtZUKjmHuAsSCn+qY= 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ileljfwo.fsf@kapio-technology.com> Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.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. 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