From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by dpdk.org (Postfix) with ESMTP id 9654A12A8 for ; Wed, 17 Jun 2015 16:47:02 +0200 (CEST) Received: by obbsn1 with SMTP id sn1so34478777obb.1 for ; Wed, 17 Jun 2015 07:47:02 -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; bh=jlAJUNhqvCQdsnGXt/3VBweFXMw04bfCVVxe8pQgZP4=; b=0Gk+B1K20hZgS/KOHJfhaNrMR17VVszD0YBcUzXO9aoWxnrMSvI8rnCOcyN1kJubnH ejFmQIXBoDjVu/OhihAFTQXd1jzuJzfEO0gHNNbBmeAngGhlE1UjIMgq2dG83E3bUlPg 88sYQppV5LZnO+UJSTx9GyvEtE5BZV+eUD1Ixs2vOyGMd5L2NonC0aS/lYQX23UlSYql MtvnsC60ONNpW19Ubn2rPbiJMoC5pXsSgwU5o1wVZeYDa3s9mpt4gF0oDbeSoKNUYLqM g1MeLVFeVh/w5mNhV52CqWc8zB/eX5iKfuWAIoDkvT2TnQEzEp0kjabTOFkqDJsZAE0/ UgbQ== MIME-Version: 1.0 X-Received: by 10.182.87.137 with SMTP id ay9mr4868722obb.68.1434552422043; Wed, 17 Jun 2015 07:47:02 -0700 (PDT) Received: by 10.76.95.200 with HTTP; Wed, 17 Jun 2015 07:47:01 -0700 (PDT) In-Reply-To: <6388992.ny7qEppTdV@xps13> References: <1433525705-17041-1-git-send-email-maryam.tahhan@intel.com> <1433525705-17041-3-git-send-email-maryam.tahhan@intel.com> <6388992.ny7qEppTdV@xps13> Date: Wed, 17 Jun 2015 10:47:01 -0400 Message-ID: From: Kyle Larose To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 2/4] ethdev: expose extended error stats 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, 17 Jun 2015 14:47:02 -0000 On Wed, Jun 17, 2015 at 9:58 AM, Thomas Monjalon wrote: [...] > > You are extending the generic stats. This is not the idea behind xstats. > The xstats are specific to the driver. > Furthermore we should migrate some "not really generic stats" to xstats > in order to keep only the really basic and common stats in rte_eth_stats. > By the way, in order to avoid duplicated code when getting generic stats > through xstats API, we need to change the implementation of > rte_eth_xstats_get() to add generic stats automatically, even if the > driver provide some xstats. This may be the wrong thread for this, and perhaps this question has been answered (I couldn't find anything relating to it), but I have a related question regarding exposing stats that are not captured in the current device independent api (rte_eth_stats_get). Is there a recommended strategy for displaying MIB interface stats for applications using DPDK? For example, consider the IF-MIB (http://www.ietf.org/rfc/rfc2233.txt). It provides three "normal" in packet counters: ifHCInUcastPkts ifHCInMulticastPkts ifHCInBroadcastPkts Looking at rte_eth_stats, the structure returned by rte_eth_stats_get, we can only retrieve the total number of in packets, and the total number of in multicast packets. We can't retrieve the number of in broadcast packets. This means that we neither display ifHCInUcastPkts (which needs us to subtract mulicast and broadcast from the total), nor ifHCInBroadcastPkts. While I understand that some devices may not support classifying packets into such categories, I would think that most NICs would try to allow applications to conform the fairly established standards such as the IF-MIB. One would think that maybe xstats would allow this: these nics have low level stats that provide this information. However, consumers of the API would need to understand each NIC's implementation of the xstats API to use it, making it somewhat cumbersome to use. I'd think that it makes sense for the MIB information to live in a device-independent, well-defined API. Does it make sense to provide sufficient information in the eth_stats_get function to provide support for the various interface stats mibs? Alternatively, does it make sense to make a new function or API tailored to providing this support? It could be device independent (unlike xstats), while allowing each driver to choose whether or not it supports it. I'm using a fairly old version of DPDK (1.7.1), but from looking at the master branch (http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.h), it looks like the structure hasn't really changed. I've been struggling to figure out the right away to approach this, so any thoughts/insights would be much appreciated. Thanks, Kyle