Hi Reinette,
On 6/20/2024 5:49 PM, Reinette Chatre wrote:
Hi Babu,
On 6/18/24 2:02 PM, Moger, Babu wrote:
On 6/13/24 19:54, Reinette Chatre wrote:
On 5/24/24 5:23 AM, Babu Moger wrote:
when reading, then the read will come back as Unavailable.
Should this not rather be "Unassigned"? According to the docs the
counters
will return "Unavailable" right after reconfigure so it seems that there
are scenarios where an "assigned" counter returns "Unavailable". It
seems
more
useful to return "Unassigned" that will have a new specific meaning that
overloading existing "Unavailable" that has original meaning of "try
again" ....
but in this case trying again will be futile.
Hardware returns "Unavailable" in both the cases. So, thought of
reporting the same without any interpretation.
I do not see these as the same. When a counter is assigned and its
read returns "Unavailable" then the user reasonably expects that
retry will work.
When a counter is not assigned then no amount of retries will result
in data. How is user space expected to distinguish between the two
scenarios that return the same error with such significantly different
meaning? rdtgroup_mondata_shows() can just peek into the monitor
group state and see if a counter is assigned and immediately
return "Unassigned" if no counter is assigned, no? I see no need
for it to IPI another CPU and try to read a counter that it already knows
will be futile. This seems unnecessary and the generic "Unavailable" is
not helpful to user space.
Sure. Will change it to report "Unassigned" in these cases.
Thanks
--
- Babu Moger
