From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16018D53B for ; Mon, 19 Jun 2023 19:05:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BC52C433C9; Mon, 19 Jun 2023 19:05:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687201516; bh=gd3acZnwvDULf6VisNuWpFCXVpO5cdtOMi2SDfzKdsU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Q9QyqatTt8FUgfHowG9AjRr9P7vqn/9E37rSAbDYQVfxLATxFkIs17+gPqtLNgwd6 D1plL8v1JwKj2XtjmZu7xbzPjvz2+xNVtQXqGD9KnIyH++0V05F3/V+NWkM4CcC5kI 7M2dXbNLh2fkI3Jo2MTS1QIcf7l/ltLazmdHhmQ24BEy77o7Wz3WsQnKIVSvbHAh6r XwjY3LoMfFzKPg/6MGRbnnuYC6a41A3QScQrSoRQwoBEToeMaQ3+QaZJD0S+4K3dsB DKbORhJ6FXDYvee6XVjm8MXGSdYVbuZ5RRs/NR8Q+hvtWNweeT+27igjVOZawbcbLC rSl+RaDcdSk+g== Date: Mon, 19 Jun 2023 12:05:15 -0700 From: Jakub Kicinski To: Vlad Buslov Cc: Saeed Mahameed , "David S. Miller" , Paolo Abeni , Eric Dumazet , Saeed Mahameed , , Tariq Toukan , Gal Pressman Subject: Re: [net-next 07/15] net/mlx5: Bridge, expose FDB state via debugfs Message-ID: <20230619120515.5045132a@kernel.org> In-Reply-To: <87r0q7uvqz.fsf@nvidia.com> References: <20230616201113.45510-1-saeed@kernel.org> <20230616201113.45510-8-saeed@kernel.org> <20230617004811.46a432a4@kernel.org> <87v8fjvnhq.fsf@nvidia.com> <20230619112849.06252444@kernel.org> <87r0q7uvqz.fsf@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 19 Jun 2023 21:34:02 +0300 Vlad Buslov wrote: > > Looks like my pw-bot shenanigans backfired / crashed, patches didn't > > get marked as Changes Requested and Dave applied the series :S > > > > I understand the motivation but the information is easy enough to > > understand to potentially tempt a user to start depending on it for > > production needs. Then another vendor may get asked to implement > > similar but not exactly the same set of stats etc. etc. > > That could happen (although consider that bridge offload functionality > significantly predates mlx5 implementation and apparently no one really > needed that until now), but such API would supplement, not replace the > debugfs since we would like to have per-eswitch FDB state exposed > together with our internal flags and everything as explained in my > previous email. Because crossing between eswitches incurs additional cost? > > Do you have customer who will need this? > > Yes. But strictly for debugging (by human), not for building some > proprietary weird user-space switch-controller application that would > query this in normal mode of operation, if I understand your concern > correctly. > > > At the very least please follow up to make the files readable to only > > root. Normal users should never look at debugfs IMO. > > Hmm, all other debugfs' in mlx5 that I tend to use for switching-related > functionality debugging seems to be 0444 (lag, steering, tc hairpin). > Why would this one be any different? Querying the stats seems generally useful, so I'd like to narrow down the access as much as possible. This way if the usage spreads we'll hear complaints and can go back to creating a more appropriate API.