Re: RDE Enablement

[Ed Tanous <edtanous@google.com>]

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).

>
> 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.

>
> Thanks,
> Deepak