From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 032065A62 for ; Wed, 20 Jan 2016 16:14:37 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id l65so183252135wmf.1 for ; Wed, 20 Jan 2016 07:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=BuTlZKs0Dzghik14H0PN2Yupgst9j3zHg+qOtOCHlY8=; b=X8MXFhtj5xNv7hDBgB6FJiRZcqQrS+ULo2eOoekSKRUU0oIYkWcag9N6XoX8iuUVtu xyGqQfGhqFJNFI6jrwGIPiwBM1CrtOnpZRHjji3Vajgh382NSGTr/eH6C+X4tFG+hFAo ZzOrZox+BOKWC5euWkSpOsVa46nlbe8hdORNqh+i7pjQGW4fS53NcLLW0L7JVBqVeFL0 3A2M0CZZJKhi2G0nYhXG/Xbw6ZGwZMofitoM7M7ZiWfIXJLeTGw392Z7zjb43CmodxXe 5SflcoeTGdqiIoB3gLPAs+BvV1v37dEYDjJOYNPsYzcni7oK3djMENzmgm9AAAS3TUlC R9hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=BuTlZKs0Dzghik14H0PN2Yupgst9j3zHg+qOtOCHlY8=; b=myQ2fgeM48fvpakKhm7Faf+873Kcf4HQz9vUtCMkCxkFo18TydFpQ0h3Ghimx+PJb7 GuvTRhQwzsdkb12/TcQ5CXXoZMh2jsAwwMKToZw1ZFmv7EBrtn+cVFjmWGqcOJAkBtXE wmp4SJqqBZOFSJBjq1eNTL4dI2ukNTqOZequFrgXt3BDshQzVKdD9MQ3EX2y0i2klgMU W/o120AHECs/VvuMTz+qAs4ruA8+FEh4ML6UhkPjyi04kpM3rqkovNYxdMzG9MQUw9z2 DZNw4vaX7EBlHuufHYrfrni7wcXItwt+TVv5ViYzoqWkrj590ZePEODHd4HwWv6tUoAr ZQZA== X-Gm-Message-State: AG10YORnYsdmC/pJSEJBa4PDqoevB8W3BidVXam+FHKhWTcKN1aOuqmnk5nbCzF3slgKEAWc X-Received: by 10.28.16.8 with SMTP id 8mr4930915wmq.77.1453302876715; Wed, 20 Jan 2016 07:14:36 -0800 (PST) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id u191sm25622117wmd.4.2016.01.20.07.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 07:14:35 -0800 (PST) From: Thomas Monjalon To: "Van Haaren, Harry" Date: Wed, 20 Jan 2016 16:13:34 +0100 Message-ID: <3240763.FVKPEEMrPZ@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1453300086-3756-1-git-send-email-harry.van.haaren@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:14:37 -0000 2016-01-20 10:03, Kyle Larose: > 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 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. > > > > 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. +1 Please also consider this work in progress about link speed information: http://dpdk.org/dev/patchwork/patch/7995/