Re: [PATCH v4 00/31] Introduce SCMI Telemetry FS support

>>>
>>> There is more stuff that indeed is configurable per the SCMI spec
>>> but these additional params are hidden into the SCMI Telemetry protocol
>>> layer (the initial patches in this series) and NOT made available to
>>> the driver/users of the protocol (like the SCMI FS driver that sits on
>>> top)
>>
>> Do you assume that there will get significantly more config options added in the
>> future for user space to configure?
> 
> No, I dont think so...the only planned extensions were to support more
> performant read access mechanisms, i.e. direct mmap'ability of FW/Kernel
> SCMI Telemetry shared memory areas...BUT that will immediately dump all
> the bulk of the lower layer protocol work into the tools domain...and

Right. I guess you would hide that in library code, and provide a stable API
towards tools such that they won't have to worry about the implementation
details regarding how the values are obtained exactly.

[...]

>>>
>>> ...most of the other entries in the tree are simply RO properties of the DEs
>>> that have been discovered at enumeration time.
>>
>> Is this bulk-reading relevant for performance or just a "nice to have" ?
>>
> 
> I suppose depends on your usage pattern: it is definitely relevant
> because the main collection mechanism are shared memory areas (SHMTIs)
> between the platform firmware and the Kernel: such areas being accessed
> from 2 differnt worlds concurrently come with a SCMI-specified
> synchro/consistency mechanism based simply on a pair of sequence numbers
> placed at the start and at the end of the SHMTI, so that the FW increases
> such magic numbers in a well-known way before and after updating the SHMTI
> values, so that the kernel can detect (without any interlocking mechanism)
> if a platform write happened in the middle of its reads...

Okay, so sequence counters to detect concurrent changes and retry.

> 
> ...so if you read one single DE 64bit value, under the hood the kernel
> would have had to really perform at leats 3 reads from the SHMTI to check
> the consistecy of that single read...
> 
> ... while if you do a bulk_read the overhead due to the consistecy
> checks gets 'spread' across a number of DEs because the kernel will snapshot
> the whole SHMTIs (potentially KBytes) between the 2 consistency reads

That makes sense.

I guess a user space library could implement some kind of caching (bulk-read,
then provide clean access to individual DEs) to hide the details from the tools?

> 
> ...the good side effect of all of this is that I can leverage such
> sequence number to optimize reads..i.e. do NOT even try to read anything
> if the new sequnce number is unchanged from the last one I cached on the
> last successfull read of this value...

Right.

> 
> So at the end I would say it is NOT simply a nice to have BUT it is
> certainly only the first step towards a more performant alternative access
> (like with mmaps)...it depends on the usage pattern...I am not sure what
> mechanism is used by our tools more...

Okay.

>>
>> Yes. How high-priority is the fs side? Or would a tool using a library to access
>> this information also work in the first step?
>>
> 
> I have to sync with tools on this...because they are stiil probably
> using currently the FS, but it was already planned for the future to move to
> a more low level access (ioctl/mmap)...
> 
> ...my aim would be, at this point, to favour this transition without sudden
> breaking their current world (and have to expatriate :P)
> 
> ..from my personal point of view, I would certainly like to still have the
> FUSE layer for ease of testing and verification on my side...but it is just
> a nice to have... 

Okay, what I thought. I assume the most important part is to be able to grab
telemetry data in an efficient way on a system to then share it with some
monitoring agent. Manually digging through the FS to inspect data (debugging,
..) is probably less relevant for the target use case.

>> Okay, so a single writer (admin) changing stuff could get picked up my possibly
>> many concurrent readers?
> 
> Mmm...not sure what you mean here...
> 
> If you configure your Telemetry as you desire and start collecting data via
> readers, BUT then some other process changes configs under your belt, that is
> allowed as said, and so your analisys could be impacted...(something turned off
> as an example, or update interval changed)...

I was rather wondering about "turning on more" concurrently. But yeah, makes sense.

(it's the same situation other system-wide settings. If one app enables KSM and
the another one disables KSM, inconsistency is unavoidable)

>>
> 
> Thanks a lot, David !

Let's hope for some guidance regarding the FS side soon.

But yeah, avoiding the in-kernel FS sounds completely reasonable at this point.

-- 
Cheers,

David