> From: David Harton (dharton) [mailto:dharton at cisco.com]
> Sent: Friday, February 5, 2016 9:16 PM
> To: Van Haaren, Harry ; Thomas
> Monjalon
> Cc: dev at dpdk.org; Tahhan, Maryam ;
> Mcnamara, John
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> From: Van Haaren, Harry [mailto:harry.van.haaren at intel.com]
>
> > From: David Harton
> > Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
> >
> > Hi folks,
> >
> > I didn't see any follow up to this response.
>
> I thi
+John,
> From: David Harton
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> Hi folks,
>
> I didn't see any follow up to this response.
I think you may have missed one:
http://dpdk.org/ml/archives/dev/2016-January/032211.html
>
> Howeve
On Tue, Feb 2, 2016 at 7:44 AM, Tahhan, Maryam
wrote:
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
>> Sent: Friday, January 22, 2016 8:49 PM
>> To: Igor Ryzhov
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] Future Direction for rte_eth
anks,
Dave
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Harton (dharton)
> Sent: Friday, January 22, 2016 2:26 PM
> To: Van Haaren, Harry ; Thomas Monjalon
>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_st
On Mon, Feb 01, 2016 at 04:47:56PM +, David Harton (dharton) wrote:
> Hi folks,
>
> I didn't see any follow up to this response.
>
> My original concern was rte_eth_stats_get() moving away from a more
> conventional based definition (note, I believe Matthew Hall made an
> interesting
> From: David Harton
>
> enum rte_eth_stat_e {
> /* accurate desc #1 */
> RTE_ETH_STAT_1,
> /* accurate desc #2 */
> RTE_ETH_STAT_2,
> ...
> }
> struct rte_eth_id_stat {
> rte_eth_stat_e id;
> uin64_t value;
> }
>
> int rte_eth_id_stats_num(uint8_t port_id, uint32_t
> > > Do you see a fundamental problem with parsing the strings to
> > > retrieve values?
> >
> > I think parsing strings is expensive CPU wise
>
> Parsing the strings can be done once at startup, and the index of the
> statistics in the array cached. When actually reading statistics, access
> of
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
2016-01-22 16:04, David Harton:
> I think parsing strings is expensive CPU wise
[...]
> wondering if something that is performance friendly for the user/application
> and flexible for the drivers is possible.
I think we need some numbers from experimentations and some requirements.
How many
+Jay, (@all, please keep everybody in the CCs :)
> From: David Harton (dharton) [mailto:dharton at cisco.com]
> To: Van Haaren, Harry ; Thomas Monjalon
> > > xstats are driver agnostic and have a well-defined naming scheme.
> >
> > Indeed, described here:
> >
> > xstats are driver agnostic and have a well-defined naming scheme.
>
> Indeed, described here:
> http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-
> statistics-api
Thanks for sharing. I do think what is in the link is well thought out but it
also may not match how the
On Fri, Jan 22, 2016 at 06:02:24PM +0300, Igor Ryzhov wrote:
> 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
+ Harry
2016-01-22 14:40, David Harton:
> Hi Maryam,
>
> I'm not dictating they be re-added (although adding would be nice) but more
> important I'm trying to express an application view point rather than a
> driver view point.
>
> I completely understand how a driver wants to be able to
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
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
> + Harry
Hey all,
> xstats are driver agnostic and have a well-defined naming scheme.
Indeed, described here:
http://dpdk.org/doc/guide
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, January 22, 2016 2:44 PM
> To: Tahhan, Maryam ; David Harton
> (dharton)
> Cc: dev at dpdk.org; olivier.matz at 6wind.com; Van Haaren, Harry
>
> Subject: Re: [dpdk-dev] Future Direction
> They were marked as deprecated to deter people from using them
> > in the
> > > future, but haven't been removed from all the driver
> > implementations yet.
> > > The Registers that remain undeprecated are those considered to be
> > generic.
> > >
> &
c.
> >
> > Which registers are you particularly interested in that have been
> > deprecated? Can you elaborate on what you mean by " scenarios
> where a
> > static view is expected "
> >
> > Thanks in advance.
> >
> > Best Regards,
uot; scenarios where a
> static view is expected "
>
> Thanks in advance.
>
> Best Regards,
> Maryam
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Harton
> > (dharton)
> > Sent: Wednesday, January
Of David Harton
> (dharton)
> Sent: Wednesday, January 20, 2016 5:19 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> I see that some of the rte_eth_stats have been marked deprecated in 2.2
> that are returned by rte_eth_stats_get(). A
On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry <
harry.van.haaren at intel.com> wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
>
> > + Harry
>
> Hey all,
>
>
I see that some of the rte_eth_stats have been marked deprecated in 2.2 that
are returned by rte_eth_stats_get(). Applications that utilize any number of
device types rely on functions like this one to debug I/O issues.
Is there a reason the stats have been deprecated? Why not keep the stats
23 matches
Mail list logo
