Per queue stats

[Stephen Hemminger <stephen@networkplumber.org>]

...
> >>> The stats queue mapping was a feature that was hinted at being removed.
> >>> It only exists because of HW limitations on Intel ixgbe NIC and SW
> >>> limitations from RTE_ETHDEV_QUEUE_STAT_CNTRS.
> >>>  
> >>
> >>
> >> We have a plan to remove 'RTE_ETHDEV_QUEUE_STAT_CNTRS', by moving queue
> >> stats to xstats.
> >>
> >> But ixgbe limitation is there.
> >>  
> >>> Perhaps there should be a generic SW emulation for this the mapping?
> >>>  
> >>
> >> Ack, cc'ed Bruce.
> >> But I am not sure ROI of the effort at this stage.  
> > 
> > Not sure what the specific ask for me is here. :-) Overall, I think moving
> > queue stats to xstats is the best way to go.
> >   
> 
> cc'ed because of "generic SW emulation" comment.
> 
> I was thinking if this mapping can be done transparent to the user by
> driver mapping queue <-> stats_register before reading stats, but @Bruce
> let me know this won't work because the stats tracking only happens
> after the mapping.
> 
> @Stephen, do you have something specific in your mind for SW emulation
> for mapping?

Probably not worth doing mapping tables for SW drivers.

My preference would be something like:
	1. Introduce new API's rte_ethdev_get_queue_stats() and rte_ethdev_reset_queue_stats().
           with callbacks in ethdev ops.
           if driver does not support this, then do a shim in ethdev that uses old stats fields.
        2. Mark the stats mapping API's as deprecated and always return error.
           Making special case for ixgbe at this point really is not worth maintaining.
        3. After all drivers converted over, drop the fields in ethdev stats for queues.
           And fix the examples, etc. Yes this would be a big API change.

Would take a year to get done (ie 25.11).