From: Igor Ryzhov <iryzhov@nfware.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
Date: Fri, 22 Jan 2016 18:02:24 +0300 [thread overview]
Message-ID: <B62D4F9D-6272-4B99-A6E2-5F77A5B62FFC@nfware.com> (raw)
In-Reply-To: <27428043.8pduO1a1Qt@xps13>
Hello, everyone.
How about exposing stats according to IF-MIB?
Statistics to be exposed are - octets, unicast packets, multicast packets, broadcast packets, errors and discards for both TX and RX.
These counters are basic and implemented by most of drivers.
All other driver-specific counters can be exposed by xstats.
Best regards,
Igor
> 22 янв. 2016 г., в 17:44, Thomas Monjalon <thomas.monjalon@6wind.com> написал(а):
>
> 2016-01-22 14:18, Tahhan, Maryam:
>> So what can be enabled again in struct rte_eth_stats from what was already there is the equivalent of:
>> * rx_length_errors
>> * rx_crc_errors
>> * rx_missed_errors - the deprecation notice was removed for this field.
>> * multicast
>>
>> What should be added in to distinguish between errors and drops. struct rte_eth_stats :
>> * rx_errors
>> * tx_errors
>>
>> As for the detailed rx errors and tx errors I'm open to feedback from you folks as to what should go in and what is too detailed. These weren't in struct rte_eth_stats previously, they are available through xstats and are uniformly named across the drivers. Oliver + Harry any thoughts?
>>
>> David I assume you are looking for all the missing fields to be added?
>
> They are not missing. They just not exactly match ones having a
> long history in Linux kernel.
> Please let's avoid to blindly mimic others without thinking
> about modern needs.
>
>>>> From: David Harton
>>>>> Is there a reason the stats have been deprecated? Why not keep
>>>>> the stats in line with the standard linux practices such as
>>>>> rtnl_link_stats64?
>
next prev parent reply other threads:[~2016-01-22 15:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 17:18 David Harton (dharton)
2016-01-22 11:07 ` Tahhan, Maryam
2016-01-22 13:40 ` David Harton (dharton)
2016-01-22 14:18 ` Tahhan, Maryam
2016-01-22 14:40 ` David Harton (dharton)
2016-01-22 14:48 ` Thomas Monjalon
2016-01-22 15:22 ` Van Haaren, Harry
2016-01-22 15:53 ` Jay Rolette
2016-01-22 16:04 ` David Harton (dharton)
2016-01-22 16:37 ` Thomas Monjalon
2016-01-22 16:41 ` Van Haaren, Harry
2016-01-22 19:26 ` David Harton (dharton)
2016-01-28 9:37 ` Van Haaren, Harry
2016-02-01 16:47 ` David Harton (dharton)
2016-02-01 21:23 ` Matthew Hall
2016-02-02 11:40 ` Van Haaren, Harry
2016-02-05 21:16 ` David Harton (dharton)
2016-02-19 8:59 ` Tahhan, Maryam
2016-01-22 14:44 ` Thomas Monjalon
2016-01-22 14:48 ` Tahhan, Maryam
2016-01-22 15:02 ` Igor Ryzhov [this message]
2016-01-22 20:48 ` Matthew Hall
2016-02-02 12:44 ` Tahhan, Maryam
2016-02-02 13:47 ` Kyle Larose
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=B62D4F9D-6272-4B99-A6E2-5F77A5B62FFC@nfware.com \
--to=iryzhov@nfware.com \
--cc=dev@dpdk.org \
--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).