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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.