Getting DIMM size in Redfish

[Ed Tanous]

On 10/10/19 8:01 PM, Lei YU wrote:
> This mail is to discuss how to get DIMM size in Redfish (bmcweb).
> 
> Currently, bmcweb does not report DIMM size because it's not
> implemented, and we are trying to implement this.
> 
> The DIMM interface is defined in [phosphor-dbus-interface][1], which
> does not provide any metadata.
> 
> For OpenPOWER systems, the size information is provided in `PrettyName`, e.g.
> 
>     "PrettyName": "DDR4-2666 32GiB 64-bit ECC RDIMM"

My issue with this is twofold.

1. So far as I can tell, there's no formal definition for what this
string should entail.  phosphor-dbus-interfaces lists it as "The human
readable name of the item."  Parsing this as a machine readable
parameter doesn't meet that intent.

2. I don't think that interface covers the full range of DIMM parameters
that can be set in Redfish.

> 
> It is guaranteed to be a string with 5 parts, and we could parse this
> string to get the size.

Where do you see this "guarantee"?  I'm not finding it anywhere.  Out of
curiosity, if the 5 params are guaranteed, what does it state when the
DIMM is non-ECC?

> I do not know how other systems (e.g. x86 or ARM) get the DIMM size.
> 
> During the [review][2] , Ed suggested creating an appropriate
> interface for the DIMM size.
> 
> It's a good suggestion, but it could be complicated to be implemented:

Given that this is something that all systems of all types are likely to
use, I think it's well worth taking the time to implement it in a
sustainable way.

> * The information is sent by host via inband IPMI as FRU;
> * In ipmid, the code to handle FRU is generic and part of the code is
> generated, so it could be hard to make a specific change for DIMM
> size.
> 
> So the question to the community is, how other systems get the DIMM size?
> Knowing this, we could try to design a generic method to handle the case.

On x86 there's a similar mechanism called Managed Data Region, which is
sent through one of 3(ish) transports and sends the SMBIOS table down to
the BMC.  I think the key here is that there needs to be an interface
for that daemon to publish.

> 
> Otherwise, we will have to write specific code, either in ipmid or in
> bmcweb, to get such specific values.

I think you've already found the interface proposal.  Lets work that
through so it meets everyone's needs.