On 10/4/2024 9:40 PM, Stephen Hemminger wrote:
> ...
>>>>> 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).
>
The problem with existing a API, 'rte_eth_stats_get()', is it has queue
stats fixed sized array which limits us also for some cases causes
unnecessary memory consumption.
Our solution for now is move queue stats to xstats, as it is flexible
this solves the problem, but as you said in other thread xstats is free
form and may be hard for the application to use it.
One option is we can add some more data to the xstats, to help
application to consume it easier, like number of queues just before the
queue stats and define queue stats formatting syntax.
But if we will go with API option, instead of adding new queue stats
('rte_ethdev_get_queue_stats()'), we can update the existing
'rte_eth_stats_get()' to return dynamic number of queue stats.
And we need to find someone to own this task.
Above is for queue stats, it does not solve the mapping issue, as we
need it for a few drivers and we already have the APIs, I am for just
keeping them as it is, they are not causing any burden to us.
