IPMI Sensor Name limitation of 16 bytes

[Rohit Pai]

Hello,



Below I have the proposal for a simple algorithm which seem to work for the sensors names we have in our platforms.

Any feedback on making it more generic and reusable would be appreciated.



Step 1: Split the given name into sub words using predefined delimiter set, remove all delimiters, and combine the sub words, remember the position of the delimiters. Some examples of delimiter are _, space, -, camelCase pattern, etc. Combine the words without delimiters and exit if the new string is less than 16 chars.

Step 2: Start from the first sub word and repeat for all the sub words.

               2.1: if the sub word character length is less than allowed_min_char_length then skip and leave it as it is.

               2.2: else remove all the characters from the sub word which appear after the offset allowed_min_char_length

               2.3: Stop the abbreviation process if the total length of the new string is less than 16 chars.

Step 3: Start by setting threshold as ( allowed_min_char_length - 1 ) and repeat by decreasing threshold by 1 in each iteration until it reaches value 1.

               3.1: if the sub word character length is less than threshold then skip and leave it as it is.

               3.2: else remove all the characters from the sub word which appear after the offset threshold.

               3.3: Stop the abbreviation process if the total length of the new string is less than 16 chars.

Step 4    Remove sub words starting from the first sub word until we reach last sub word or if the total length of the new string is less than 16 chars.



Some unit test data with allowed_min_char_length set to value 5.


Length
Input Names
New Length
Short Names
14
CPU_0_Energy_0
14
CPU_0_Energy_0
20
GPU_0_DRAM_0_Power_0
15
GPU0DRAM0Power0
20
CPU_0_EDPViolation_0
15
CPU0EDPViolati0
26
ProcessorModule_0_Energy_0
15
ProcModu0Energ0
23
Baseboard_HSC_0_Power_0
15
BasebHSC0Power0
50
ProcessorModule_0_MemCntl_0_PageRetirementCountl_0
15
PM0MC0PaReCoun0







Thanks

Rohit



-----Original Message-----
From: Ed Tanous <edtanous at google.com>
Sent: Tuesday, May 9, 2023 2:22 AM
To: Rohit Pai <ropai at nvidia.com>
Cc: openbmc at lists.ozlabs.org
Subject: Re: IPMI Sensor Name limitation of 16 bytes



External email: Use caution opening links or attachments





On Mon, May 8, 2023 at 10:52 AM Rohit Pai <ropai at nvidia.com<mailto:ropai at nvidia.com>> wrote:

>

> Would like to receive feedback about this solution and any alternative that may exist to solve this problem. Any pointers on existing patch also would be helpful.

>



Overall, I'm in support of this feature, and I think it would give us a lot more flexibility in Redfish in the future.  It's one of the design points that I really wasn't happy with in the original sensor subsystem.



While I think most would directly take this feature, one thing to keep in mind is that there were organizations that had the requirement to be able to map IPMI names to Redfish names using a reasonable algorithm.  Having this supported would break that requirement, but I think that's something that an individual machine can figure out by coming up with names less than 16 characters for platforms that have this requirement.



One thing I would also very much caution against is reducing the performance of SDR listing any more than it already is.  It's current performance is at basically the bare minimum of where it should be, so if making this change requires any additional dbus calls, that's going to cause some problems.





One thing I had advocated for in the past is simply doing algorithmic string reduction until it fits, using the most common transforms.



Power -> Pwr

Temperature -> Temp

Power Supply -> PSU



These are algorithms that humans already do today manually to get to the 16 char length, so in theory you could do this transform without any changes needed to the actual platform configs, and if someone wanted to reverse the algorithm later and come up with the Redfish string, they could.  Something you could consider, but there might be simpler ideas that meet your goals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230628/754d096d/attachment-0001.htm>