From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Kyle Larose <eomereadig@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats
Date: Wed, 20 Jan 2016 14:45:05 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA61285F3A6@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <CAMFWN9mJ-L02pKxe2BypG2=3rWGUDMKqBeN5Nmo1W6=rpN6tYg@mail.gmail.com>
Hi Kyle,
> From: Kyle Larose [mailto:eomereadig@gmail.com]
> On Wed, Jan 20, 2016 at 9:28 AM, Harry van Haaren
> <harry.van.haaren@intel.com> wrote:
> > This patch exposes link duplex, speed, and status via the
> > existing xstats API.
>
> I'm slightly confused by this. Why are we exposing operational
> properties of the chip through an API which I thought was primarily
> targeting statistics?
In a fault-detection situation, link state is a good item to monitor - just like
the rest of the statistics on the NIC.
> When I think of statistics and a NIC, I think of
> values which are monotonically increasing. I think of values that are
> derived primary from the packets flowing through the system. I do not
> think of link state, link speed and duplex, which have nothing to do
> with packets, and are not monotonic.
Link state, and speed seem a good fit to me. I'll admit I'm not sure about duplex, and would be happy to respin the patch without duplex if the community would prefer that.
> Should we not have a separate API to get this type information? I
> mean, just because we have a generic "string to uint64_t" map doesn't
> mean we should toss in anything that can fit into a uin64_t.
In theory we could create a new API for this, but I think the current xstats API is a good fit for exposing this info, so why create extra APIs? As a client of the DPDK API, I would prefer more statistics in a single API than have to research and implement two or more APIs to retrieve the information to monitor.
I'm working on exposing keep-alive statistics using an xstats style API, I'll the patches later today so we can discuss them too.
Regards, -Harry
next prev parent reply other threads:[~2016-01-20 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 14:28 Harry van Haaren
2016-01-20 14:35 ` Kyle Larose
2016-01-20 14:45 ` Van Haaren, Harry [this message]
2016-01-20 15:03 ` Kyle Larose
2016-01-20 15:13 ` Thomas Monjalon
2016-01-20 15:58 ` Van Haaren, Harry
2016-01-20 18:36 ` Stephen Hemminger
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=E923DB57A917B54B9182A2E928D00FA61285F3A6@IRSMSX102.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=dev@dpdk.org \
--cc=eomereadig@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 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).