DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Tahhan, Maryam" <maryam.tahhan@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/4] ethdev: expose extended error stats
Date: Mon, 22 Jun 2015 15:35:51 +0000	[thread overview]
Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536A4404C3@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <558825D3.2090106@6wind.com>

<snip>
> >>> + packets. */
> >>>  };
> >>
> >> You are extending the generic stats. This is not the idea behind xstats.
> >> The xstats are specific to the driver.
> >
> > I'd followed the example of:
> > http://patchwork.dpdk.org/dev/patchwork/patch/85/
> > to added generic extended stats (at least what I thought were
> > generic). I think that dropped packets should fall under struct
> > rte_eth_stats, and should perhaps be left there, as most NICs/drivers
> > should be able to provide that number. Would this be an agreeable
> solution?
> >
> > I have no other way to expose the total MAC errors and the total PHY
> > errors without Adding counters into struct ixgbe_hw_stats, but I wasn't sure
> if this was allowable, is it?
> >
> > The only other option is to round up all the errors into ierrors,
> > without having the granularity of what errors fall under. Is the
> > latter option to sum up the values under one umbrella preferred?
> 
> As Thomas explained, I think we should avoid adding fields in struct
> rte_eth_stats. This structure already contains statistics that are specific to
> some hardware drivers. We should try to go in the opposite direction and
> remove all the fields that do not apply to all nics (physical or virtual). For me, it
> would be only something like (rx, tx, rx_bytes, tx_bytes, rx_errors, tx_errors).
> 
> The xstats framework allows you to add any driver or hardware specific stats
> and I think it's the proper place to add them for ixgbe.
> 


Alright that sounds good.

> By the way, something could be modified in xstats framework. Today, the
> behavior is:
> - if ethdev->dev_ops->xstats_get != NULL, call it
> - else, dump the generic stats in xstats format

As it happens I did do this in: http://dpdk.org/dev/patchwork/patch/5324/ 
but I will reverse the order as what happens now is xstats from the driver
are displayed first and will look at always dumping generic stats in xstats format
as you mention below.

> 
> A better behavior could be:
> - Always dump the generic stats in xstats format
> - and if thdev->dev_ops->xstats_get != NULL, add driver-specific stats
> 
> This would avoid to duplicate code that dumps generic stats in all drivers.
> 
> So, to summarize what I think should be done for stats/xstats:
> 1. modify xstats behavior as described above 2. add the xstats dev_ops in
> ixgbe, it will dump the new stats
> 
> Bonus:
> 3. identify all the specific stats that could be removed from
>    rte_eth_stats and start to mark them as deprecated.
> 

Will do.

> 
> Regards,
> Olivier

Thanks
Maryam
<snip>

  reply	other threads:[~2015-06-22 15:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 17:35 [dpdk-dev] [PATCH 0/4] expose ixgbe extended stats to dpdk apps Maryam Tahhan
2015-06-05 17:35 ` [dpdk-dev] [PATCH 1/4] ixgbe: expose extended error statistics Maryam Tahhan
2015-06-08 13:26   ` Tahhan, Maryam
2015-06-10  0:51   ` Stephen Hemminger
2015-06-10 14:24     ` Tahhan, Maryam
2015-06-17 12:52     ` Thomas Monjalon
2015-06-05 17:35 ` [dpdk-dev] [PATCH 2/4] ethdev: expose extended error stats Maryam Tahhan
2015-06-17 13:58   ` Thomas Monjalon
2015-06-17 14:47     ` Kyle Larose
2015-06-22 14:12     ` Tahhan, Maryam
2015-06-22 15:12       ` Olivier MATZ
2015-06-22 15:35         ` Tahhan, Maryam [this message]
2015-06-05 17:35 ` [dpdk-dev] [PATCH 3/4] testpmd: extend testpmd to show all extended stats Maryam Tahhan
2015-06-05 17:35 ` [dpdk-dev] [PATCH 4/4] app: replace dump_cfg with proc_info Maryam Tahhan
2015-06-05 21:08   ` Thomas Monjalon
2015-06-08 13:45     ` Tahhan, Maryam
2015-06-08 14:22       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1A27633A6DA49C4A92FCD5D4312DBF536A4404C3@IRSMSX109.ger.corp.intel.com \
    --to=maryam.tahhan@intel.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).