openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ed Tanous <edtanous@google.com>
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
Date: Wed, 21 Jul 2021 07:23:38 -0700	[thread overview]
Message-ID: <CAH2-KxCxy0G6cYRPkOKe+YQBX1h7No--fn7JLDz4yskwTMjyOw@mail.gmail.com> (raw)
In-Reply-To: <CAM=TmwWJ58RaUhjW9axXdyPDSsePG0zQsnxh-FKSj4C5nZG0Kg@mail.gmail.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

  reply	other threads:[~2021-07-21 14:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 20:26 Garrett, Mike (HPE Server Firmware)
2021-06-10 20:32 ` Ed Tanous
2021-06-10 20:59   ` Garrett, Mike (HPE Server Firmware)
2021-06-10 23:06     ` Andrew Jeffery
2021-06-11  6:53     ` Deepak Kodihalli
2021-06-11 13:31       ` Garrett, Mike (HPE Server Firmware)
2021-08-09 13:50       ` Garrett, Mike (HPE Server Firmware)
2021-07-21 14:16     ` Ed Tanous
2021-07-21  8:34   ` Deepak Kodihalli
2021-07-21 14:23     ` Ed Tanous [this message]
2021-07-26 13:53       ` Garrett, Mike (HPE Server Firmware)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH2-KxCxy0G6cYRPkOKe+YQBX1h7No--fn7JLDz4yskwTMjyOw@mail.gmail.com \
    --to=edtanous@google.com \
    --cc=deepak.kodihalli.83@gmail.com \
    --cc=mike.garrett@hpe.com \
    --cc=openbmc@lists.ozlabs.org \
    --subject='Re: RDE Enablement' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).