RE: RDE Enablement

["Garrett, Mike (HPE Server Firmware)" <mike.garrett@hpe.com>]

Sorry for the delayed response but comments inline.

Thanks,

Mike

> -----Original Message-----
> From: Ed Tanous <edtanous@google.com>
> Sent: Wednesday, July 21, 2021 9:24 AM
> To: Deepak Kodihalli <deepak.kodihalli.83@gmail.com>
> Cc: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>;
> OpenBMC Maillist <openbmc@lists.ozlabs.org>
> Subject: Re: RDE Enablement
> 
> On Wed, Jul 21, 2021 at 1:34 AM Deepak Kodihalli
> <deepak.kodihalli.83@gmail.com> wrote:
> >
> > Hi All,
> >
> > On Fri, Jun 11, 2021 at 2:02 AM Ed Tanous <edtanous@google.com> wrote:
> > >
> > > On Thu, Jun 10, 2021 at 1:26 PM Garrett, Mike (HPE Server Firmware)
> > > <mike.garrett@hpe.com> wrote:
> > > >
> > > > Greetings,
> > > >
> > > > I'm am interested to know if there has been any organized discussion or
> development on Redfish Device Enablement (RDE - DMTF DSP0218) for
> moving encoded Redfish data across PLDM/MCTP interfaces.  We are
> interested in promoting this standard and are willing to lead a reference
> implementation for OpenBMC if there is not yet something in progress.  If
> there is something in progress, can you point me at the work because I
> would love to see it.
> > >
> > > We are interested in this as well, although we are in the early
> > > stages of looking into it.  Ideally we'd like to have OpenBMC
> > > support add in cards (NICs, Accelerators, ect) that supported this
> > > functionality, and make that data available to the normal OpenBMC
> > > channels (Redfish/ipmi/ect).
> >
> > I had a couple of questions on RDE, and I wonder if this has crossed
> > your mind as you started looking at RDE, or if this is
> > misunderstanding on my part:
> 
> As a preface, you might consider asking these questions on the DMTF forums
> if they're not specific to OpenBMC.  The authors of the RDE spec are present
> in those places and generally have good answers for what the "intent" was.
> 
> >
> > 1) I understand the problem RDE tries to solve in terms of avoiding
> > having device-specific knowledge/code on the BMC, but doesn't PLDM
> > also solve a similar problem? For example, if a device supported PLDM
> > Type 2 (and other PLDM specs such as the one for FRU, etc), the BMC
> > could convert PLDM to Redfish. I understand this may not be as
> > convenient as RDE but it still solves the device-specific code
> > problem, PLDM being a standard protocol as well. Am I missing
> > something here? Is it just that RDE is more convenient than PLDM to
> > Redfish conversion, or is there more to it - for example, PLDM
> > can't/isn't intended to be converted to Redfish, in an
> > effective/lossless way?
> 
> From my limited knowledge, it's because RDE can be losslessly converted to
> Redfish, and the BMC can take the form of a proxying agent.  In the PLDM to
> Redfish model, the BMC would need upfront knowledge of every interface
> in PLDM, and how it maps to the Redfish tree, which could get onerous.  In
> the RDE model, embedded controllers end up taking the same form as an
> individual server would to a redfish aggregator, which is advantageous in that
> all the aggregator code can be reused (if OpenBMC had an aggregator).
> 
[MikeG] 
I agree:  First of all, RDE is PLDM (type 6).  PLDM type 2 is a good solution for sensors, but RDE abstracts many of the other "non-sensor" aspects of device management including "actions".  For example, RDE can enable a BMC to present a storage controller's logical volumes, complete with the actions needed to create new volumes, or remove them.  Some adapters may only need Type 2 sensor information, but many advanced adapters have a much more complex management interface, and a Redfish model to match.  In these cases, a solid RDE implementation will provide a way to not have to link in adapter-specific or vendor-specific management libraries to the BMC.  Additionally, since the Redfish model comes from the adapter, it should be more consistent when that adapter is inserted into various systems with different BMC implementations, allowing the adapter to have more control over its Redfish presentation.  Finally, RDE includes the capability to signal Redfish events to the BMC, which can then be transmitted to subscribers.

The "good" is that theoretically, RDE offers very high fidelity Redfish management of an adapter while the BMC mostly plays a passthrough role.
The "less-good" is that for some aspects of management, the BMC would need to parse the data and add it to dbus for things the BMC wishes to aggregate (e.g. the sensor model) - things Type 2 does well.


> >
> > 2) Is RDE specific to a class of devices? Some of the documents I see
> > stress on I/O adapters. Would be it odd to implement RDE on devices
> > like Accelerators, CPU, etc?
> 
> RDE is meant for devices with a small footprint.  There has been discussion in
> the past about allowing it on the host interface for standard out of band
> communication, but I don't think that ever materialized.  Putting it on
> accelerators or CPUs seems logical to me given that their controllers are small
> footprint.
> 
[MikeG] 
RDE is not specific to a class of devices.  It is appropriate when a device is "behind" a BMC and has a Redfish-defined data model the BMC needs to present to clients.

> >
> > Thanks,
> > Deepak