From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by dpdk.org (Postfix) with ESMTP id 86A192A5F for ; Thu, 29 Oct 2015 13:55:03 +0100 (CET) Received: by oifu63 with SMTP id u63so31188147oif.2 for ; Thu, 29 Oct 2015 05:55:03 -0700 (PDT) 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=V08oGn7+0VSZsP6Odilpny4HM5LKG8DaI3rLY7RDo6Y=; b=VDhyesSmJjelkZ0YUnSDx+//EZbC28KvDnBmv4QKnjSZhSGpOI6DaD9faR1n57jhG3 xradCxK72jYejWixhzDpycOy3dGUeMkw5xeKdD93DWSSdT7HMnUmZ1C/D6/xrZLS/8v4 5pWerbPuLczUSVpG921yvNjPRpm9og6nFZ+AXGrXzkOvRYZZ0uqXty7/LDOV/d6jzE0c r6ZxAwBT+NNijsTQ0Hyv+ftpEFpbPKovvCfKgzJJPxisUCjYZ6f+sYmUeRBasRWGqz8A envxgQ6AbmIuI3/mRHEop302aH78QVP6VX9+0ti6IkwTBQjnNwF97gpQSNuzXpdMr5io qYlw== MIME-Version: 1.0 X-Received: by 10.182.247.99 with SMTP id yd3mr832449obc.37.1446123302946; Thu, 29 Oct 2015 05:55:02 -0700 (PDT) Received: by 10.76.175.72 with HTTP; Thu, 29 Oct 2015 05:55:02 -0700 (PDT) In-Reply-To: <9689034CEF26614CAB4B447EEAAF98E918241CB2@wtl-exchp-1.sandvine.com> References: <1443606022-13581-2-git-send-email-harry.van.haaren@intel.com> <1445528914-27636-1-git-send-email-harry.van.haaren@intel.com> <9689034CEF26614CAB4B447EEAAF98E918241AD3@wtl-exchp-1.sandvine.com> <20151029063216.4675da65@samsung9> <9689034CEF26614CAB4B447EEAAF98E918241CB2@wtl-exchp-1.sandvine.com> Date: Thu, 29 Oct 2015 08:55:02 -0400 Message-ID: From: Kyle Larose To: Tom Crugnale , Stephen Hemminger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port 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: Thu, 29 Oct 2015 12:55:03 -0000 Stephen, Ultimately the issue we are trying to solve is that there is no device independent way to get any detailed statistics from NICs controlled by DPDK. These statistics are quite useful, not just for diagnostics, but for long term reporting. People using DPDK-based NFV products in a production environment are not going to be happy that they cannot, for example, see how the packet size bucket counters varied over time using some sort of monitoring tool. The only alternative I can see to providing an API within DPDK is to build our own abstraction layer triggered off the driver name/pci ids/etc. I expect other people would end up doing this as well. This seems like a waste of effort when an abstraction layer already exists within DPDK. So, let's consider solving the problem within DPDK. One option is to use well-defined names for a given xstat that has the same semantics across NICs, while continuing to allow NICs to expose any stats that don't fall into this category. Another option is to provide an API with a well-defined set of stats, perhaps using an enum. In order for a stat to be added to this list, it needs to be part of a standard (such as http://tools.ietf.org/html/rfc2819). Does anybody else see the need for something like this? We're more than willing to do the work. We'd like to make sure we have the right API, though. Thanks, Kyle On Wed, Oct 28, 2015 at 8:55 PM, Tom Crugnale wrot= e: > I understand. Is this the reason that that strings were used to identify= the xstat types? An enum type would be much more efficient instead of doi= ng string copies when retrieving the stats, but the number of enum entries = would quickly grow out of control as device specific stats were added. > > In this case, I'm actually referring to the stats that are common to all = NICs. For example, for the received fragmented packets counter, there are = three strings that identify this value: rx_fragment_packets (igb), rx_fragm= ent_errors (ixgbe), rx_fragmented_packets (i40e). > I was thinking of making those names consistent. Perhaps the reason why = they were different in the first place is that each of the device datasheet= s refers to these exact names. > > Tom > > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Wednesday, October 28, 2015 5:32 PM > To: Tom Crugnale > Cc: Harry van Haaren; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port XStats > > On Wed, 28 Oct 2015 17:35:09 +0000 > Tom Crugnale wrote: > >> Hi Harry, >> >> We are planning on using the xstats API for periodic stats collection th= rough a polling thread. This would be done in a generic NIC agnostic manne= r, which would require that the xstats identifiers have consistent naming a= mongst all of the NIC types. It would likely be polled several times per s= econd and would only gather a subset of all available xstats types. >> >> I have reviewed your patches and am interested in providing some API enh= ancements and bugfixes. Are you willing to provide feedback on such change= s? >> >> Thank you, >> Tom > > The whole point of xstats is to allow device specific statistics. > Consistent use of names is good from a user interface point of view, but = probably not a hard requirement. >