Re: Future Direction for rte_eth_stats_get()

From: David Harton (dharton) [mailto:dharton@cisco.com]
Sent: Friday, February 5, 2016 9:16 PM
To: Van Haaren, Harry <redacted>; Thomas
Monjalon [off-list ref]
Cc: dev@dpdk.org; Tahhan, Maryam <redacted>;
Mcnamara, John [off-list ref]
Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()

quoted

From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]

quoted

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

Apologies Harry!  I didn't see your original post because the IT gods had
decided your response was "Junk" mail and it didn't make it to my
dev_dpdk.org mail folder. :(

A colleague actually pointed me to this post separately today.  I've made
the Junk mailer a little smarter now...hopefully.

<snip>

quoted

I'm looking at the enum thinking it will grow out of control.
Have you thought about adding metadata for RX / TX, PF / VF?

Yes, after thinking about it more I think it could get crazy.

quoted

If metadata info is added, it would make retrieving a set of
statistics based on a certain mask much easier. Do you think this may

be of use?

Actually, I put a fair bit of thought into things and then realized, why re-
invent the wheel?
Why not follow the ethtool stats model?

struct rte_eth_xstats_name {
    char name[RTE_ETH_XSTATS_NAME_SIZE]; };

extern int rte_eth_xtats_count(uint8_t port_id, unsigned *count); extern
int rte_eth_xtats_strings(uint8_t port_id, unsigned count, struct
rte_eth_xtats_name *names); extern int rte_eth_xtats_values(uint8_t
port_id, unsigned count, uint64_t *values);

The existing API could be left in-place and these could be added for folks
that don't want to grab the strings all the time.

The cons compared to providing an enum or extending struct
rte_eth_stats are:
 - you have to perform a query immediately after the device is attached
 - doesn't require conformity...which has pros and cons

I'm actually testing the changes above if folks think this would be a
reasonable compromise I can patch them up.

I think this is a reasonable compromise. 

I still feel the feedback myself and others gave about rte_eth_stats_get()
being closer to a standard MIB should get some consideration.

 +1

Applications that run with a number of different drivers/device types
likely want to avoid having to create "xstats mapping tables" every time
a new device pops out just so they can debug problems.

Thanks,
Dave