Proposal for pldmtool

Proposal for pldmtool

[Tom Joseph]

Hi All,

I wanted to put down initial thoughts on "pldmtool" which is a utility 
for controlling PLDM enabled devices. The naming of the utility was 
influenced by ipmitool which is a client utility to control IPMI enabled 
devices. The pldmtool acts as the requester and sends the PLDM message 
to target any PLDM enabled device. The PLDM response message is 
processed and expressed in human readable format.  This proposal needs 
to be considered on the basis of the pldm design 
(https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md). 
These are possible pldmtool usage scenarios.

* pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM 
daemon will have a D-Bus interface to accept PLDM requests.
* pldmtool can target other management controllers connected to BMC 
implementing PLDM stacks.
* A provision to run pldmtool targeting OpenBMC over a custom network 
port and route the request to the PLDM daemon.

These are the some of the salient features in the pldmtool that

* Provide user friendly command options
* Debug options to print detailed PLDM messages.
* Leverage libmctp and libpldm library getting developed for 
communicating with MCTP layer and for encoding/decoding PLDM messages. 
(https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)

The host firmware stacks typically have runtime constraints. If there is 
interest in having pldmtool run on host firmware then pldmtool will have 
to be written in C. Apart from this consideration the natural choice 
will be to develop this in modern C++.

This mail is a feeler to seek the interests of the community. I will be 
keen to follow-up this with a design template.

Thanks,
Tom

RE: Proposal for pldmtool

[Supreeth Venkatesh]

Tom,

Thanks for sending this out as a feeler.
This sounds like a logical next step after implementation of PLDM and MCTP.
However, I have a couple of initial questions.

" A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
     PLDM was intended for inside the box communications.

2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.

3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.

Thanks,
Supreeth
-----Original Message-----
From: Tom Joseph <tomjose@linux.vnet.ibm.com>
Sent: Monday, February 18, 2019 4:09 AM
To: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>; Alexander Amelkin <a.amelkin@yadro.com>; benwei@fb.com
Subject: Proposal for pldmtool

Hi All,

I wanted to put down initial thoughts on "pldmtool" which is a utility for controlling PLDM enabled devices. The naming of the utility was influenced by ipmitool which is a client utility to control IPMI enabled devices. The pldmtool acts as the requester and sends the PLDM message to target any PLDM enabled device. The PLDM response message is processed and expressed in human readable format.  This proposal needs to be considered on the basis of the pldm design (https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md).
These are possible pldmtool usage scenarios.

* pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM daemon will have a D-Bus interface to accept PLDM requests.
* pldmtool can target other management controllers connected to BMC implementing PLDM stacks.
* A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon.

These are the some of the salient features in the pldmtool that

* Provide user friendly command options
* Debug options to print detailed PLDM messages.
* Leverage libmctp and libpldm library getting developed for communicating with MCTP layer and for encoding/decoding PLDM messages.
(https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)

The host firmware stacks typically have runtime constraints. If there is interest in having pldmtool run on host firmware then pldmtool will have to be written in C. Apart from this consideration the natural choice will be to develop this in modern C++.

This mail is a feeler to seek the interests of the community. I will be keen to follow-up this with a design template.

Thanks,
Tom

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Proposal for pldmtool

[Deepak Kodihalli]

On 21/02/19 11:12 PM, Supreeth Venkatesh wrote:
> Tom,
> 
> Thanks for sending this out as a feeler.
> This sounds like a logical next step after implementation of PLDM and MCTP.
> However, I have a couple of initial questions.
> 
> " A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
> 1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
>       PLDM was intended for inside the box communications.

I'll let Tom comment as well, but I agree that this use-case probably 
does not exist. This tool serves more as a debug aid for in-band PLDM 
communication.

> 2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.

What if the PLDM device the BMC is talking to does not implement Redfish?

> 3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.

Probably for debug - quickly test a remote PLDM device without having to 
write a full blown requester application. Similar to how it would help 
when it runs on the BMC.

> Thanks,
> Supreeth

Regards,
Deepak

Re: Proposal for pldmtool

[Tom Joseph]

On Thursday 21 February 2019 11:12 PM, Supreeth Venkatesh wrote:
> Tom,
>
> Thanks for sending this out as a feeler.
> This sounds like a logical next step after implementation of PLDM and MCTP.
> However, I have a couple of initial questions.
>
> " A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
> 1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
>       PLDM was intended for inside the box communications.
I agree that PLDM is intended for inside the box communications. The 
proposal is not to use it as an external interface, but rather give a 
provision to run pldmtool from outside the box.
>
> 2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.
I think it is not guaranteed that the management controllers 
implementing pldm has https support.
>
> 3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.
This might not be a typical use-case to run pldmtool from host firmware. 
I was curious to know if someone will be interested to do this. But we 
do see a possibility of running it from Host OS targeting the BMC, just 
like ipmitool can be run from the host targeting the BMC via KCS/BT 
interfaces.
>
> Thanks,
> Supreeth
> -----Original Message-----
> From: Tom Joseph <tomjose@linux.vnet.ibm.com>
> Sent: Monday, February 18, 2019 4:09 AM
> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>; Alexander Amelkin <a.amelkin@yadro.com>; benwei@fb.com
> Subject: Proposal for pldmtool
>
> Hi All,
>
> I wanted to put down initial thoughts on "pldmtool" which is a utility for controlling PLDM enabled devices. The naming of the utility was influenced by ipmitool which is a client utility to control IPMI enabled devices. The pldmtool acts as the requester and sends the PLDM message to target any PLDM enabled device. The PLDM response message is processed and expressed in human readable format.  This proposal needs to be considered on the basis of the pldm design (https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md).
> These are possible pldmtool usage scenarios.
>
> * pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM daemon will have a D-Bus interface to accept PLDM requests.
> * pldmtool can target other management controllers connected to BMC implementing PLDM stacks.
> * A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon.
>
> These are the some of the salient features in the pldmtool that
>
> * Provide user friendly command options
> * Debug options to print detailed PLDM messages.
> * Leverage libmctp and libpldm library getting developed for communicating with MCTP layer and for encoding/decoding PLDM messages.
> (https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)
>
> The host firmware stacks typically have runtime constraints. If there is interest in having pldmtool run on host firmware then pldmtool will have to be written in C. Apart from this consideration the natural choice will be to develop this in modern C++.
>
> This mail is a feeler to seek the interests of the community. I will be keen to follow-up this with a design template.
>
> Thanks,
> Tom
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: Proposal for pldmtool

[Emily Shaffer]

On Wed, Feb 27, 2019 at 10:29 PM Tom Joseph <tomjose@linux.vnet.ibm.com> wrote:
>
>
>
> On Thursday 21 February 2019 11:12 PM, Supreeth Venkatesh wrote:
> > Tom,
> >
> > Thanks for sending this out as a feeler.
> > This sounds like a logical next step after implementation of PLDM and MCTP.
> > However, I have a couple of initial questions.
> >
> > " A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
> > 1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
> >       PLDM was intended for inside the box communications.
> I agree that PLDM is intended for inside the box communications. The
> proposal is not to use it as an external interface, but rather give a
> provision to run pldmtool from outside the box.

I'm a little confused how this is different from external interface.
Could you elaborate? Are you trying to route through the host first?

> >
> > 2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.
> I think it is not guaranteed that the management controllers
> implementing pldm has https support.
> >
> > 3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.
> This might not be a typical use-case to run pldmtool from host firmware.
> I was curious to know if someone will be interested to do this. But we
> do see a possibility of running it from Host OS targeting the BMC, just
> like ipmitool can be run from the host targeting the BMC via KCS/BT
> interfaces.
> >
> > Thanks,
> > Supreeth
> > -----Original Message-----
> > From: Tom Joseph <tomjose@linux.vnet.ibm.com>
> > Sent: Monday, February 18, 2019 4:09 AM
> > To: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>; Alexander Amelkin <a.amelkin@yadro.com>; benwei@fb.com
> > Subject: Proposal for pldmtool
> >
> > Hi All,
> >
> > I wanted to put down initial thoughts on "pldmtool" which is a utility for controlling PLDM enabled devices. The naming of the utility was influenced by ipmitool which is a client utility to control IPMI enabled devices. The pldmtool acts as the requester and sends the PLDM message to target any PLDM enabled device. The PLDM response message is processed and expressed in human readable format.  This proposal needs to be considered on the basis of the pldm design (https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md).
> > These are possible pldmtool usage scenarios.
> >
> > * pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM daemon will have a D-Bus interface to accept PLDM requests.
> > * pldmtool can target other management controllers connected to BMC implementing PLDM stacks.
> > * A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon.
> >
> > These are the some of the salient features in the pldmtool that
> >
> > * Provide user friendly command options
> > * Debug options to print detailed PLDM messages.
> > * Leverage libmctp and libpldm library getting developed for communicating with MCTP layer and for encoding/decoding PLDM messages.
> > (https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)
> >
> > The host firmware stacks typically have runtime constraints. If there is interest in having pldmtool run on host firmware then pldmtool will have to be written in C. Apart from this consideration the natural choice will be to develop this in modern C++.
> >
> > This mail is a feeler to seek the interests of the community. I will be keen to follow-up this with a design template.
> >
> > Thanks,
> > Tom
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>


-- 
Emily Shaffer

Re: Proposal for pldmtool

[Tom Joseph]

On Friday 01 March 2019 12:06 AM, Emily Shaffer wrote:
> On Wed, Feb 27, 2019 at 10:29 PM Tom Joseph <tomjose@linux.vnet.ibm.com> wrote:
>>
>>
>> On Thursday 21 February 2019 11:12 PM, Supreeth Venkatesh wrote:
>>> Tom,
>>>
>>> Thanks for sending this out as a feeler.
>>> This sounds like a logical next step after implementation of PLDM and MCTP.
>>> However, I have a couple of initial questions.
>>>
>>> " A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
>>> 1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
>>>        PLDM was intended for inside the box communications.
>> I agree that PLDM is intended for inside the box communications. The
>> proposal is not to use it as an external interface, but rather give a
>> provision to run pldmtool from outside the box.
> I'm a little confused how this is different from external interface.
> Could you elaborate? Are you trying to route through the host first?

On a box shipped to customers, there would be no external interface to 
send PLDM messages to BMC. This can be considered as a debug option for 
lab purpose.

>
>>> 2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.
>> I think it is not guaranteed that the management controllers
>> implementing pldm has https support.
>>> 3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.
>> This might not be a typical use-case to run pldmtool from host firmware.
>> I was curious to know if someone will be interested to do this. But we
>> do see a possibility of running it from Host OS targeting the BMC, just
>> like ipmitool can be run from the host targeting the BMC via KCS/BT
>> interfaces.
>>> Thanks,
>>> Supreeth
>>> -----Original Message-----
>>> From: Tom Joseph <tomjose@linux.vnet.ibm.com>
>>> Sent: Monday, February 18, 2019 4:09 AM
>>> To: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>; Alexander Amelkin <a.amelkin@yadro.com>; benwei@fb.com
>>> Subject: Proposal for pldmtool
>>>
>>> Hi All,
>>>
>>> I wanted to put down initial thoughts on "pldmtool" which is a utility for controlling PLDM enabled devices. The naming of the utility was influenced by ipmitool which is a client utility to control IPMI enabled devices. The pldmtool acts as the requester and sends the PLDM message to target any PLDM enabled device. The PLDM response message is processed and expressed in human readable format.  This proposal needs to be considered on the basis of the pldm design (https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md).
>>> These are possible pldmtool usage scenarios.
>>>
>>> * pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM daemon will have a D-Bus interface to accept PLDM requests.
>>> * pldmtool can target other management controllers connected to BMC implementing PLDM stacks.
>>> * A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon.
>>>
>>> These are the some of the salient features in the pldmtool that
>>>
>>> * Provide user friendly command options
>>> * Debug options to print detailed PLDM messages.
>>> * Leverage libmctp and libpldm library getting developed for communicating with MCTP layer and for encoding/decoding PLDM messages.
>>> (https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)
>>>
>>> The host firmware stacks typically have runtime constraints. If there is interest in having pldmtool run on host firmware then pldmtool will have to be written in C. Apart from this consideration the natural choice will be to develop this in modern C++.
>>>
>>> This mail is a feeler to seek the interests of the community. I will be keen to follow-up this with a design template.
>>>
>>> Thanks,
>>> Tom
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>