Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp3476163rwl; Mon, 27 Mar 2023 14:53:51 -0700 (PDT) X-Google-Smtp-Source: AKy350b1TDREdayfyD58Q2hB5ynuR/L7g1J6DOXth5pGlAHGB8mbB/cCpOFeO0JNxwIHwtd0rFhM X-Received: by 2002:a17:906:6a2a:b0:878:711d:9310 with SMTP id qw42-20020a1709066a2a00b00878711d9310mr15870230ejc.1.1679954031451; Mon, 27 Mar 2023 14:53:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679954031; cv=none; d=google.com; s=arc-20160816; b=tdk05nU/dJUdR1LX4M87CsMo2vJQ3zYvPp5YYkfF5pINAoPxTCGZyDGTaclXn2CnjZ qLl7fMbyP+ZaoaSoc3Wug+lQ2RnkbjRlVUkWfSEHambEgdFVI9lgJrBwC6GJLHBMuSgL 7gQl+KZAUzgk9ROn5TdMJy8w/I///2lVN6Y4797SshZTeyRgUfw97CbHFoQVeYZ31X8U BLXBR8I2A1CB8qb+L0lwcejaMv9W7EaASFfDDiQr/xCBtx2UCmNWJvnGlEm6m8Q4MS84 Zuy5NLEfaR6686XX1DhJVwu24DfFavi1676iCRIotaCrsiycxFdCT87RCCXfTLGoyQAA T+3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=5gN1X2K/tBvjGjLYNzWH7jfewqFqoB9kkVZmSTyexhk=; b=w1PPsA/kmf6Kk6BjnEm4AJ7+bl6InghNgyBaXbUM/W3x1ty4CF0WnZvwddJirY8C+0 EsPaRoxK9lNQI46bIounOPu8Kz/uuR98CWiBcgajyTdCJ5r8bYxJ+KosPzjcMFZsnPbU AJafJh8MmBMYhS1bb7JIWTZmQx03vg5b7xFj76luJanUe94Ie7YLwYM/g/3fQqQMsJum pKtNglyR+f8nBLeq2ZRcSmkvcOjLNoIbnjiPkBd3BYNnrycROKJMgvyW6LgEFruuyWZf RTBCdihcKZuCEqSD+ClvX13R7C9uwcjWgFwmft4T9FaUtTJ9Jf0ZlFp8Ca8oUEiHw3r9 GkMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a8-20020a1709066d4800b0093de089f33esi8836611ejt.841.2023.03.27.14.53.27; Mon, 27 Mar 2023 14:53:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230070AbjC0Vwm (ORCPT + 99 others); Mon, 27 Mar 2023 17:52:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35736 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbjC0Vwk (ORCPT ); Mon, 27 Mar 2023 17:52:40 -0400 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67C3E2D66; Mon, 27 Mar 2023 14:52:37 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 0E9AE1884564; Mon, 27 Mar 2023 21:52:35 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 02FC225042EC; Mon, 27 Mar 2023 21:52:35 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id ED01F9B403E2; Mon, 27 Mar 2023 21:52:34 +0000 (UTC) X-Screener-Id: e32ae469fa6e394734d05373d3a705875723cf1e Received: from fujitsu (2-104-116-184-cable.dk.customer.tdc.net [2.104.116.184]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 38ACD91201E3; Mon, 27 Mar 2023 21:52:34 +0000 (UTC) From: Hans Schultz To: Vladimir Oltean 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?Q?Cl=C3=A9ment_L=C3=A9ger?= , 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 In-Reply-To: <20230327160009.bdswnalizdv2u77z@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> Date: Mon, 27 Mar 2023 23:49:58 +0200 Message-ID: <87pm8tooe1.fsf@kapio-technology.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 27, 2023 at 19:00, Vladimir Oltean wrote: > A reasonable question you could ask yourself is: why do my BR_FDB_OFFLOADED > entries have this flag in the software bridge in the first place? > Did I add code for it? Is it because there is some difference between > mv88e6xxx and ocelot/felix, or is it because dsa_fdb_offload_notify() > gets called in both cases from generic code just the same? > > And if dsa_fdb_offload_notify() gets called in both cases just the same, > but no other driver except for mv88e6xxx emits the SWITCHDEV_FDB_DEL_TO_BRIDGE > which you've patched the bridge to expect in this series, then what exactly > is surprising in the fact that offloaded and dynamic FDB entries now become > stale, but are not removed from the software bridge as they were before? Yes, I see I have missed that the dsa layer already adds the offloaded flag in dsa_slave_switchdev_event_work() in slave.c. My first approach was to use the SWITCHDEV_FDB_ADD_TO_BRIDGE event and not the SWITCHDEV_FDB_OFFLOADED event as the first would set the external learned flag which is not aged out by the bridge. I have at some point earlier asked why there would be two quite equivalent flags and what the difference between them are, but I didn't get a response. Now I see the difference and that I cannot use the offloaded flag without changing the behaviour of the system as I actually change the behaviour of the offloaded flag in this version of the patch-set. So if the idea of a 'synthetically' learned fdb entry from the driver using the SWITCHDEV_FDB_ADD_TO_BRIDGE event from the driver towards the bridge instead is accepted, I can go with that? (thus removing all the changes in the patch-set regarding the offloaded flag ofcourse)