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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71FBFC433E1 for ; Wed, 19 Aug 2020 00:24:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3FF5520772 for ; Wed, 19 Aug 2020 00:24:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597796665; bh=FWPHmdBQHTKcM6rXSZw0Vlb7kcy9ULMPqViOX64OtjY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=WA3pAOeim/oex8OX6PPYqQR1D3jSf6ihLiqiza0moW/yqLzUN+nDrmqWF1q7udd3f frcUa/7qdhyECFJTfmiH3juL195/1Lnnqx/QwLuSg7CeZrXu5u41DkrcdJukh3VuUL XLv5syGw9P918CZQ7vVE8kcu7DprbSAtfmRDkpU8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726703AbgHSAYY (ORCPT ); Tue, 18 Aug 2020 20:24:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:43874 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726367AbgHSAYX (ORCPT ); Tue, 18 Aug 2020 20:24:23 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF5B620738; Wed, 19 Aug 2020 00:24:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597796663; bh=FWPHmdBQHTKcM6rXSZw0Vlb7kcy9ULMPqViOX64OtjY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BDj4dLCl+8QjKaFZMOXPRbTEHE5jjXmwManAIhBL+fSrZ4fSE9fBxF911ae9p3X+x KlwOR7BPOKiSAkAEE5GGmbq+X8ZYo9NEfAXv7KySuibChC8plqsKgbrsiO8cpIZSLD Vs2rltF0q8igwayvHur2kzxbLwCUoRe+epHJZETg= Date: Tue, 18 Aug 2020 17:24:19 -0700 From: Jakub Kicinski To: Ido Schimmel Cc: netdev@vger.kernel.org, davem@davemloft.net, jiri@nvidia.com, amcohen@nvidia.com, danieller@nvidia.com, mlxsw@nvidia.com, roopa@nvidia.com, dsahern@gmail.com, andrew@lunn.ch, f.fainelli@gmail.com, vivien.didelot@gmail.com, saeedm@nvidia.com, tariqt@nvidia.com, ayal@nvidia.com, eranbe@nvidia.com, mkubecek@suse.cz, Ido Schimmel Subject: Re: [RFC PATCH net-next 0/6] devlink: Add device metric support Message-ID: <20200818172419.5b86801b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20200817125059.193242-1-idosch@idosch.org> References: <20200817125059.193242-1-idosch@idosch.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, 17 Aug 2020 15:50:53 +0300 Ido Schimmel wrote: > From: Ido Schimmel > > This patch set extends devlink to allow device drivers to expose device > metrics to user space in a standard and extensible fashion, as opposed > to the driver-specific debugfs approach. I feel like all those loose hardware interfaces are a huge maintenance burden. I don't know what the solution is, but the status quo is not great. I spend way too much time patrolling ethtool -S outputs already. I've done my absolute best to make sure that something as simple as updating device firmware can be done in a vendor-agnostic fashion, and I'm not sure I've succeeded. Every single vendor comes up with their own twists. Long story short I'm extremely unexcited about another interface where drivers expose random strings of their picking. Maybe udp_tunnel module can have "global" stats? This would be a good topic for netconf, or LPC hallway discussion :(