From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kyle Larose Subject: Re: [PATCH] ethdev: expose link status and speed using xstats Date: Wed, 20 Jan 2016 10:03:36 -0500 Message-ID: References: <1453300086-3756-1-git-send-email-harry.van.haaren@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: "Van Haaren, Harry" Return-path: Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by dpdk.org (Postfix) with ESMTP id 2CED38E62 for ; Wed, 20 Jan 2016 16:03:37 +0100 (CET) Received: by mail-ob0-f172.google.com with SMTP id is5so8877231obc.0 for ; Wed, 20 Jan 2016 07:03:37 -0800 (PST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Harry, On Wed, Jan 20, 2016 at 9:45 AM, Van Haaren, Harry wrote: > Hi Kyle, > > In theory we could create a new API for this, but I think the current xst= ats 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 th= an have to research and implement two or more APIs to retrieve the informat= ion to monitor. > You create new APIs for many reasons: modularity, simplicitly within the API, consistency, etc. My main concern with this proposed change relates to consistency. Previously, each stat had similar semantics. It was a number, representing the amount of times something had occurred on a chip. This fact allows you to perform operations like addition, subtraction/etc and expect that the result will be meaningful for every value in the array. For example, suppose I wrote a tool to give the "rate" for each of the stats. We could sample these stats periodically, then output the difference between the two samples divided by the time between samples for each stat. A naive implementation, but quite simple. However, if we start adding values like link speed and state, which are not really numerical, or not monotonic, you can no longer apply the same mathematical operations on them and expect them to be meaningful. For example, suppose a link went down. The "rate" for that stat would be -1. Does that really make sense? Anyone using this API would need to explicitly filter out the non-stats, or risk nonsensical output. Let's also consider how to interpret the value. When I look at a stat, there's usually one of two meanings: it's either a number of packets, or it's a number of bytes. We're now adding exceptions to that rule. Link state is a boolean. Link speed is a value in mbps. Duplex is pretty much an enum. We already have the rte_eth_link_get function. Why not let users continue to use that? It's well defined, it is simple, and it is consistent. Thanks, Kyle