Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3252574rwb; Fri, 20 Jan 2023 13:24:20 -0800 (PST) X-Google-Smtp-Source: AMrXdXtpsWQHQD1Nj463EcI/MGaQLG+sCpL76Tkh/zWNa5tX5nA1pAxkzZkqiqVEf+Oimj2cgPan X-Received: by 2002:a17:906:5d1:b0:861:7a02:1046 with SMTP id t17-20020a17090605d100b008617a021046mr15946029ejt.37.1674249860663; Fri, 20 Jan 2023 13:24:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674249860; cv=none; d=google.com; s=arc-20160816; b=dif0wXgBjlnuRNsp6wUxalcRIKmBtlDJD+eFEMXZhQpZsZzaC90u9919JNi2Cki4oK takV6cVHDBsyettU/fTHUaH7yecZ0W4HwHPn3TMCsw4lbqxoRkr9CIniTHKMQ3STJdRc Y6Z2W2wB8qJp8eFk8aqUm9TLZi93JGu9lZSpkxMymzbOXRp++8h476nW2GBaSAkZivGE WjrMTqskUQH0vJ/NsU7vFASmmbE6Vd+wc+LWQNPIJQVscREywMdyfckdg4WqorHHUuGs vcRMob39UfybIR7532yZRnsPa7X+GBvrMG/tPj4N0N9FjRyyueuL1H5IFwYm1G39seS3 rGVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version; bh=Qe79gp9v6F9f07AMBV5HihIHF6Yv06nn7LnQj2QYctU=; b=UOXISOY1gQtOQWLaxTRbF1qfnVDJrdHxoj0hYBJ8Bj24BnOnf+QiU8Nivinx39JvRX ng5hllD5bFcjvUIsle+VGzu4waWzOG3ZlqCrYYtgDRCelHVYrKR/WYUaG6ibgVF/EZAD ltQumqc1XtueiE39gXpOuuprA4Es0EggoIFFdSsVdzRMpEKPGUG7kjqmWVGzNHuIYjD1 zyxZOp80/pgLHEsxg/krDkuK2soYgpHx+wvr+UYpT1yXCQXC7BcRV9PVCHF+HK+kVRWE RWRU9rlN1N2n0cz/wPlGuS+IT7Gr5cU9YhOa1/NTvSfv61IxT/iCPSupGX2oQ2aSNBng EMvw== 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 p11-20020a056402500b00b004948ab74664si45249105eda.106.2023.01.20.13.24.07; Fri, 20 Jan 2023 13:24:20 -0800 (PST) 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 S229464AbjATVQM (ORCPT + 52 others); Fri, 20 Jan 2023 16:16:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229695AbjATVQK (ORCPT ); Fri, 20 Jan 2023 16:16:10 -0500 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E86101DB94; Fri, 20 Jan 2023 13:16:05 -0800 (PST) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 4A5AF1883A74; Fri, 20 Jan 2023 21:16:03 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 412112500327; Fri, 20 Jan 2023 21:16:03 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 2D75D91201E4; Fri, 20 Jan 2023 21:16:03 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Fri, 20 Jan 2023 22:16:03 +0100 From: netdev@kapio-technology.com 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 , Claudiu Manoil , Alexandre Belloni , =?UTF-8?Q?Cl=C3=A9ment_L=C3=A9ger?= , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Russell King , Christian Marangi , 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" Subject: Re: [RFC PATCH net-next 1/5] net: bridge: add dynamic flag to switchdev notifier In-Reply-To: <20230119134045.fqdt6zrna5x3iavt@skbuf> References: <20230117185714.3058453-1-netdev@kapio-technology.com> <20230117185714.3058453-2-netdev@kapio-technology.com> <20230117230806.ipwcbnq4jcc4qs7z@skbuf> <20230119093358.gbyka2x4qbxxr43b@skbuf> <20230119134045.fqdt6zrna5x3iavt@skbuf> User-Agent: Gigahost Webmail Message-ID: <29501147c96e7e2f06c999410d42e2bf@kapio-technology.com> X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=ham 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 2023-01-19 14:40, Vladimir Oltean wrote: > On Thu, Jan 19, 2023 at 11:33:58AM +0200, Vladimir Oltean wrote: >> On Wed, Jan 18, 2023 at 11:14:00PM +0100, netdev@kapio-technology.com >> wrote: >> > > > + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); >> > > >> > > Why reverse logic? Why not just name this "is_static" and leave any >> > > further interpretations up to the consumer? >> > >> > My reasoning for this is that the common case is to have static entries, >> > thus is_dyn=false, so whenever someone uses a switchdev_notifier_fdb_info >> > struct the common case does not need to be entered. >> > Otherwise it might also break something when someone uses this struct and if >> > it was 'is_static' and they forget to code is_static=true they will get >> > dynamic entries without wanting it and it can be hard to find such an error. >> >> I'll leave it up to bridge maintainers if this is preferable to >> patching >> all callers of SWITCHDEV_FDB_ADD_TO_BRIDGE such that they set >> is_static=true. > > Actually, why would you assume that all users of > SWITCHDEV_FDB_ADD_TO_BRIDGE > want to add static FDB entries? You can't avoid inspecting the code and > making sure that the is_dyn/is_static flag is set correctly either way. Well, up until this patch set there is no option, besides entries from SWITCHDEV_FDB_ADD_TO_BRIDGE events will get the external learned flag set, so they will not be aged by the bridge, and so dynamic entries that way don't make much sense I think. Is that not right?