From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by dpdk.org (Postfix) with ESMTP id BE707C382 for ; Fri, 26 Jun 2015 16:37:48 +0200 (CEST) Received: by oiyy130 with SMTP id y130so76689035oiy.0 for ; Fri, 26 Jun 2015 07:37:48 -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=DOMbi3lYcIfzUONXXTW58xnkAmLnq8PjPEosxNgCgu0=; b=0M+zsN61U8IUle2AOjaLwO5HpEiIX8bshfuRJi8x9IJ1NrZH92EaCPtUGTW6OeXmR/ bB7VFiCRc6ylcgKKb8KqXeV2siyVMPMMHLAQXP+zXyggWgGAjiqgyma9DJnoe07Xxesd TWNijM0bipkPfZFzv0VpOUNF8L2BrgXkxJ9qW9JgEOO71suJeBiUoCMPNM3/nWfnLoBo urP60z+sdQsDHKRje2wwfGrpsJt2JkDveCBzOVlGXnFRCp1wLZfMg+A5Q4aL+XVB4RkH j+mSvGqMtYi0fdoRnp7/xkly0pYlw+C5XAXDKu3HJzSqkBQbEvT/8dmjAn7+U+fk5elE Tl7g== MIME-Version: 1.0 X-Received: by 10.202.196.146 with SMTP id u140mr1654063oif.89.1435329468129; Fri, 26 Jun 2015 07:37:48 -0700 (PDT) Received: by 10.76.95.200 with HTTP; Fri, 26 Jun 2015 07:37:48 -0700 (PDT) In-Reply-To: <1A27633A6DA49C4A92FCD5D4312DBF536A45182E@IRSMSX109.ger.corp.intel.com> References: <1435323558-169985-1-git-send-email-maryam.tahhan@intel.com> <1435323558-169985-5-git-send-email-maryam.tahhan@intel.com> <1A27633A6DA49C4A92FCD5D4312DBF536A45182E@IRSMSX109.ger.corp.intel.com> Date: Fri, 26 Jun 2015 10:37:48 -0400 Message-ID: From: Kyle Larose To: "Tahhan, Maryam" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 4/7] ethdev: remove HW specific stats in stats structs 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: Fri, 26 Jun 2015 14:37:49 -0000 Hi Maryam, I was not aware of the proc_info app. Is there any documentation on dpdk.or= g about it, or should I browse the code? Thanks, Kyle On Fri, Jun 26, 2015 at 10:30 AM, Tahhan, Maryam wrote: > > > On Fri, Jun 26, 2015 at 8:59 AM, Maryam Tahhan > wrote: > > Remove non generic stats in rte_stats_strings and mark the relevant > fields in struct rte_eth_stats as deprecated. > > Signed-off-by: Maryam Tahhan > --- > doc/guides/rel_notes/abi.rst | 11 +++++++++++ > lib/librte_ether/rte_ethdev.c | 9 --------- > lib/librte_ether/rte_ethdev.h | 30 ++++++++++++++++++++---------- > 3 files changed, 31 insertions(+), 19 deletions(-) > > diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst > index f00a6ee..957b13f 100644 > --- a/doc/guides/rel_notes/abi.rst > +++ b/doc/guides/rel_notes/abi.rst > @@ -38,3 +38,14 @@ Examples of Deprecation Notices > > Deprecation Notices > ------------------- > +* The following fields have been deprecated in rte_eth_stats: > + * uint64_t imissed > + * uint64_t ibadcrc > + * uint64_t ibadlen > + * uint64_t imcasts > + * uint64_t fdirmatch > + * uint64_t fdirmiss > + * uint64_t tx_pause_xon > + * uint64_t rx_pause_xon > + * uint64_t tx_pause_xoff > + * uint64_t rx_pause_xoff > > > > Are CRC errors (ibadcrc) truly hardware specific? Which NIC (aside from > purely virtual ones) does not have a MAC which does frame checksumming? > Likewise, which NIC doesn't drop because the PCI bus/cpu/etc is too busy = to > pull packets off of it (imissed)? > > Debugging interactions with NICs is hard enough with only CRC errors and > missed packets to go on. Without those it is close to impossible. CRC > errors are almost guaranteed any time a bare-metal application is deploye= d: > dirty fiber, bad SFPs, etc. How will users of the application be able to > determine why their packets are dropping if they can only see "in errors"= ? > > I understand that we want to avoid placing too much useless information > into these statistics structures. However, without a hardware-independent > way of accessing fairly standard networking-equipment diagnostics, I feel > like any real-world application using DPDK will be terribly cumbersome to > build: every single one will need to develop an abstraction layer which > detects the attached NICs, and loads an appropriate driver to integrate > with the xstats api. > > > > Is there any plan for such an API? If not, is it really a good idea to > deprecate these stats? > > Thanks, > > Kyle > > > > Hi Kyle > > > > If it=E2=80=99s just for debug/diagnostic purposes that this information = is being > used then I would recommend using the proc_info app which is already > integrated with xstats will give you detailed error statistics. It runs a= s > a DPDK secondary process. > > > > I=E2=80=99m not sure about crcerrors and imissed, I had taken feedback to= my > previous version of the patches onboard and made the changes based on tha= t. > > > > Regards > > Maryam >