From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9D4F741737 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org ABC724170E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IldUzgigZGpLqvOtuZQF8FxGmnj4lSM0S4waVzxMh3E=; b=W0JTb3T23ACG0KONrYo9g2b2zLcsvhdJQBbTH2isfNFefGQ5+I1OLsKMnSQJEsFXZJtLZ2tWHH0HzPhMf7YXQ10kfL9jVhC1VI/mvNNCL4i9ilsbCW0hb20+sz1KGRtsfdE+61Yw5xj3bLke4UAXF0lLXcwO9Qv9fBvHQR3j+gs= Date: Tue, 16 May 2023 13:44:28 +0300 From: Vladimir Oltean Message-ID: <20230516104428.i5ou4ogx7gt2x6gq@skbuf> References: <20230515085046.4457-1-jnixdorf-oss@avm.de> <20230516102141.w75yh6pdo53ufjur@skbuf> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: MIME-Version: 1.0 Subject: Re: [Bridge] [PATCH net-next 1/2] bridge: Add a limit on FDB entries List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikolay Aleksandrov Cc: Andrew Lunn , Florian Fainelli , Johannes Nixdorf , netdev@vger.kernel.org, Ido Schimmel , bridge@lists.linux-foundation.org, Oleksij Rempel , Eric Dumazet , Roopa Prabhu , Jakub Kicinski , Paolo Abeni , "David S. Miller" On Tue, May 16, 2023 at 01:32:05PM +0300, Nikolay Aleksandrov wrote: > Let's take a step back, I wasn't suggesting we start with a full-fledged switchdev > implementation. :) I meant only to see if the minimum global limit implementation > suggested would suffice and would be able to later extend so switchdev can use and > potentially modify (e.g. drivers setting limits etc). We can start with a simple > support for limits and then extend accordingly. The important part here is to > not add any uAPI that can't be changed later which would impact future changes. I guess adding a global per-bridge learning limit now makes sense and would not unreasonably hinder switchdev later on. The focus is on "learning limit" and not a limit to user-created entries as Johannes has currently done in v1. I don't necessarily see an urgent need for IFLA_BR_FDB_CUR_ENTRIES, given the fact that user space can dump the FDB and count what it needs, filtering for FDB types accordingly.