openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Garrett, Mike (HPE Server Firmware)" <mike.garrett@hpe.com>
To: Deepak Kodihalli <deepak.kodihalli.83@gmail.com>
Cc: Ed Tanous <edtanous@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: RE: RDE Enablement
Date: Fri, 11 Jun 2021 13:31:40 +0000	[thread overview]
Message-ID: <DF4PR8401MB06345B74D9F70517688047C28F349@DF4PR8401MB0634.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAM=TmwVTAfesxeUodQwGr=3RSvR-7sXQAmF6j5_8Wa3S8fyq3Q@mail.gmail.com>

Hi Deepak,

Integrating RDE directly into the PLDM service sounds just fine to me.

Mike

-----Original Message-----
From: Deepak Kodihalli <deepak.kodihalli.83@gmail.com> 
Sent: Friday, June 11, 2021 1:54 AM
To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
Cc: Ed Tanous <edtanous@google.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: RDE Enablement

Hi Mike,

On Fri, Jun 11, 2021 at 2:29 AM Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com> wrote:
>
> Great!  We are interested in RDE becoming ubiquitous on adapter cards so that Redfish configuration of storage and networking doesn't have to include adapter specific code.  A good success metric would be the ability to create a storage logical volume using nothing but standard Redfish operations.  In pursuit of this, a solid open source OpenBMC implementation seems like a good way to put RDE on the right footing.
>
> My initial thoughts would be to build an RDE systemd service on top of the existing pldmd service and have an upper interface into the standard dbus interfaces for inventory, status, and configuration.  However, I suspect there's some additional dbus work needed to join RDE to bmcweb because there will be a need to dynamically change the Redfish model and support things like Actions.  A requirement for this to work would be the ability to discover PLDM devices and assign IDs (MCTP EID) in order to interrogate them for RDE capabilities.  It is unclear to me that the current PLDM and MCTP code handles discovery or if it assumes devices.

The current PLDM stack upstream is mostly for the BMC as a PLDM responder, but there is work underway to make the BMC act as a PLDM requester, discover devices, etc. You should start seeing patches for these shortly (there's already https://gerrit.openbmc-project.xyz/c/openbmc/pldm/+/43465 ).

What is the reasoning behind having RDE as a separate service as opposed to being part of the PLDM service? I think one of the key aspects would be the Redfish to RDE bridge (and vice versa). We're also interested in RDE. I'd be happy to discuss/review further on the ML or on Gerrit (if you're planning to put up a design doc).

Thanks,
Deepak

  reply	other threads:[~2021-06-11 13:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 20:26 RDE Enablement 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) [this message]
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
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=DF4PR8401MB06345B74D9F70517688047C28F349@DF4PR8401MB0634.NAMPRD84.PROD.OUTLOOK.COM \
    --to=mike.garrett@hpe.com \
    --cc=deepak.kodihalli.83@gmail.com \
    --cc=edtanous@google.com \
    --cc=openbmc@lists.ozlabs.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).