[dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats

[David Harton (dharton)]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton
> Sent: Friday, April 15, 2016 10:44 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from
> xstats
> 
> The current extended ethernet statistics fetching involve doing several
> string operations, which causes performance issues if there are lots of
> statistics and/or network interfaces. This RFC patchset changes the API
> for xstats to use integer identifiers instead of strings and implements
> this new API for the ixgbe driver. Others drivers to follow.
> 
> --
> 
> Since this will involve API & ABI breakage as previously advertised, there
> are several design assumptions that need consideration:
> 
> *) id-name & id-value pairs for both lookup and query Permits out-of-order
> and non-contigious returning of names/ids/values, even though expected
> implmentations would in practice return items in sorted order by id. Is
> this sufficent/desirable future proofing? Idea is to allow possibility of
> drivers returning partial statistics.

I believe forcing drivers to match to a common id-space will become 
burdensome.  If the stats id-space isn't common then matching strings is 
probably just as sufficient as long as drivers don't add/remove stats
ad hoc between the time the device is initialized and removed.

> 
> *) Bulk name-id mapping lookup only
> At the moment individual lookup is not supported, as this would impose
> extra overheads on drivers. The assumption is that any end user would
> fetch all this data once on startup and then cache the mappings.

I'm not sure I see the value of looking up a single stat from a user
perspective.  I can see where the drivers might say that some stats
are less disruptive/etc but the user doesn't have that knowledge and
wouldn't know how to take advantage.  Usually all stats are grabbed
multiple times and the changes noted during debug sessions.

> 
> *) Replacement or additional API
> This patch replaces the current xstats API, but there is no inherant
> reason beyond maintainability why this funtionality could not be in
> addition rather than a replacement. What is consensus on this?

I came to the conclusion that replacing the existing API isn't necessary
but rather extending it so backwards compatibility could be maintained
during the previous discussions on this topic.  However, if we want to 
go forward with cleaning up in order to reduce the support drivers
provide I'm all for it.

I still believe the API we develop should follow an "ethtool stats like"
format as suggested earlier this year:

extern int rte_eth_xstats_names_get(uint8_t port_id,
        struct rte_eth_xstats_name *names, unsigned n);
extern int rte_eth_xstats_values_get(uint8_t port_id,
        uint64_t *values, unsigned n);

Again, these could be provided alongside the existing API or replace it.

I also like the idea you provided of a separate API to obtain the
xstats count rather than deriving the count by calling one of the
above functions with "dummy" values.

Again, I can provide the patches for the changes I've made that align
with this proposed API.  I just never got any feedback on it when
requested previously.

Regards,
Dave

> 
> Comments welcome.
> 
> Remy Horton (3):
>   rte: change xstats to use integer keys
>   drivers/net/ixgbe: change xstats to use integer keys
>   examples/ethtool: add xstats display command
> 
>  drivers/net/ixgbe/ixgbe_ethdev.c      | 87
> +++++++++++++++++++++++++++++++----
>  examples/ethtool/ethtool-app/ethapp.c | 57 +++++++++++++++++++++++
>  lib/librte_ether/rte_ethdev.c         | 87
> +++++++++++++++++++++++++++++++----
>  lib/librte_ether/rte_ethdev.h         | 38 +++++++++++++++
>  4 files changed, 252 insertions(+), 17 deletions(-)
> 
> --
> 2.5.5