From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oYQAE1EE+65wYIOOFz8RsoKxl1dCE+dLVnun6aSrdzw=; b=qSb9oCt9L2IUSkOslmmjkde+arjs3SJ+AufBub7AKyD/VfOR+Ivc1CCOfHGAs7i5B5 mjDp4gOP848qolOpS7n0unGbPLPB3mlrFrerQGbJ/SKLucfwp+fUJazg72dl+jYqTqbK W95aX2yqLhqJ1/77jsOp5wZSQwXo7LIISB9hWkw7Cu5hB18hoCdnQUXqD164sMC8OGlF kkEzIvo8w3UyorqTU5QdoGvQ0wnVcO+KtXhRGoaKzmL6f7MxXITph6ctjvix2AbCN7yN mhyE1khbQLTgyIKBlqxihiUQLWRmC3a6LwR5rry0LMiLbjQeVP1gggqcTk1LdKGMDbdA BB/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oYQAE1EE+65wYIOOFz8RsoKxl1dCE+dLVnun6aSrdzw=; b=ZxGqHGnB/YlqTSU6ykZBmLAlO+8PuJ0YOu2GvSgLZMoEeCJj/43cIzMOLF2iwH3EnE JGT2qXckzpgCRgNndYI6rtwjQJ0qY1UXrQHzV5WZc+sbvtDtpGLmWcK+hUcdos+VT0Nf K0E7tBU48d2S5MSSfr5WV8y/D07+VNR9tOurFipqeBPcmwwONJbAxxOLuSYtuD8AVMk1 yqwhK41JGSjpY+jNfjNrApd+x/fxJOioxCmF7Zmijq01OOXyxjUhBt/CVG3Qx4aSTe7b Ww7LiO3QEhcyNbxKgnjpX69nJn1t7XJJYkHUpeWT3MJ/JC9OsSSSoqf1I4QFMT9h/878 irQg== X-Gm-Message-State: ALoCoQmzh/pRn7l3kmZNPNWRhZFdXHRIEX7eRkrmFGhS43/KVCzgRq1rseo9JkLE/ZYTYrfsQZ4O8Z3D/TAo1yefc9vBVhEPCg== MIME-Version: 1.0 X-Received: by 10.60.128.195 with SMTP id nq3mr28921696oeb.52.1453302216615; Wed, 20 Jan 2016 07:03:36 -0800 (PST) Received: by 10.76.68.7 with HTTP; Wed, 20 Jan 2016 07:03:36 -0800 (PST) In-Reply-To: References: <1453300086-3756-1-git-send-email-harry.van.haaren@intel.com> Date: Wed, 20 Jan 2016 10:03:36 -0500 Message-ID: From: Kyle Larose To: "Van Haaren, Harry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ethdev: expose link status and speed using xstats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:03:37 -0000 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