> -----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