Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org> To: Jakub Kicinski <kuba@kernel.org> Cc: David Ahern <dsahern@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, netdev@vger.kernel.org, davem@davemloft.net, jiri@nvidia.com, amcohen@nvidia.com, danieller@nvidia.com, mlxsw@nvidia.com, roopa@nvidia.com, andrew@lunn.ch, vivien.didelot@gmail.com, tariqt@nvidia.com, ayal@nvidia.com, mkubecek@suse.cz, Ido Schimmel <idosch@nvidia.com> Subject: Re: [RFC PATCH net-next 0/6] devlink: Add device metric support Date: Sun, 23 Aug 2020 10:04:34 +0300 [thread overview] Message-ID: <20200823070434.GA400109@shredder> (raw) In-Reply-To: <20200822092739.5ba0c099@kicinski-fedora-PC1C0HJN> On Sat, Aug 22, 2020 at 09:27:39AM -0700, Jakub Kicinski wrote: > On Fri, 21 Aug 2020 19:18:37 -0600 David Ahern wrote: > > On 8/21/20 6:37 PM, Jakub Kicinski wrote: > > >>> # cat /proc/net/tls_stat > > >> > > >> I do not agree with adding files under /proc/net for this. > > > > > > Yeah it's not the best, with higher LoC a better solution should be > > > within reach. > > > > The duplicity here is mind-boggling. Tls stats from hardware is on par > > with Ido's *example* of vxlan stats from an ASIC. You agree that > > /proc/net files are wrong, > > I didn't say /proc/net was wrong, I'm just trying to be agreeable. > Maybe I need to improve my command of the English language. > > AFAIK /proc/net is where protocol stats are. > > > but you did it anyway and now you want the > > next person to solve the problem you did not want to tackle but have > > strong opinions on. > > I have no need and interest in vxlan stats. > > > Ido has a history of thinking through problems and solutions in a proper > > Linux Way. netlink is the right API, and devlink was created for > > 'device' stuff versus 'netdev' stuff. Hence, I agree with this > > *framework* for extracting asic stats. > > You seem to focus on less relevant points. I primarily care about the > statistics being defined and identified by Linux, not every vendor for > themselves. Trying to understand how we can move this forward. The issue is with the specific VXLAN metrics, but you generally agree with the need for the framework? See my two other examples: Cache counters and algorithmic TCAM counters. > No question about Ido's ability and contributions, but then again > (from the cover letter): > > > This a joint work [...] during a two-day company hackathon. The *implementation* was done during the hackathon. The *design* was done before. I sent to the team three design proposals (CLI / netlink API / device drivers API) before we landed on this. Started thinking about this idea a few months ago and the hackathon was simply a good opportunity to implement and showcase it.
next prev parent reply other threads:[~2020-08-23 7:04 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-17 12:50 [RFC PATCH net-next 0/6] devlink: Add device metric support Ido Schimmel 2020-08-17 12:50 ` [RFC PATCH net-next 1/6] devlink: Add device metric infrastructure Ido Schimmel 2020-08-17 14:12 ` Andrew Lunn 2020-08-17 12:50 ` [RFC PATCH net-next 2/6] netdevsim: Add devlink metric support Ido Schimmel 2020-08-17 12:50 ` [RFC PATCH net-next 3/6] selftests: netdevsim: Add devlink metric tests Ido Schimmel 2020-08-17 12:50 ` [RFC PATCH net-next 4/6] mlxsw: reg: Add Tunneling NVE Counters Register Ido Schimmel 2020-08-17 12:50 ` [RFC PATCH net-next 5/6] mlxsw: reg: Add Tunneling NVE Counters Register Version 2 Ido Schimmel 2020-08-17 12:50 ` [RFC PATCH net-next 6/6] mlxsw: spectrum_nve: Expose VXLAN counters via devlink-metric Ido Schimmel 2020-08-17 14:29 ` Andrew Lunn 2020-08-18 6:59 ` Ido Schimmel 2020-08-19 0:24 ` [RFC PATCH net-next 0/6] devlink: Add device metric support Jakub Kicinski 2020-08-19 2:43 ` David Ahern 2020-08-19 3:35 ` Jakub Kicinski 2020-08-19 4:30 ` Florian Fainelli 2020-08-19 16:18 ` Jakub Kicinski 2020-08-19 17:20 ` Florian Fainelli 2020-08-19 18:07 ` Jakub Kicinski 2020-08-20 14:35 ` David Ahern 2020-08-20 16:09 ` Jakub Kicinski 2020-08-21 10:30 ` Ido Schimmel 2020-08-21 16:53 ` Jakub Kicinski 2020-08-21 19:12 ` David Ahern 2020-08-21 23:50 ` Jakub Kicinski 2020-08-21 23:59 ` David Ahern 2020-08-22 0:37 ` Jakub Kicinski 2020-08-22 1:18 ` David Ahern 2020-08-22 16:27 ` Jakub Kicinski 2020-08-23 7:04 ` Ido Schimmel [this message] 2020-08-24 19:11 ` Jakub Kicinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200823070434.GA400109@shredder \ --to=idosch@idosch.org \ --cc=amcohen@nvidia.com \ --cc=andrew@lunn.ch \ --cc=ayal@nvidia.com \ --cc=danieller@nvidia.com \ --cc=davem@davemloft.net \ --cc=dsahern@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=idosch@nvidia.com \ --cc=jiri@nvidia.com \ --cc=kuba@kernel.org \ --cc=mkubecek@suse.cz \ --cc=mlxsw@nvidia.com \ --cc=netdev@vger.kernel.org \ --cc=roopa@nvidia.com \ --cc=tariqt@nvidia.com \ --cc=vivien.didelot@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).