| commit | a6575b8403f1c41e3b64a3a5db4c55e5d0fa5b1b | [log] [tgz] |
|---|---|---|
| author | vkaverap <vkaverap@in.ibm.com> | Wed Apr 03 05:33:52 2019 -0500 |
| committer | Deepak Kodihalli <dkodihal@in.ibm.com> | Mon Jun 10 13:50:51 2019 +0000 |
| tree | 165443940a5666be692959c9af79870546d0a747 | |
| parent | 26b0e57ca3074896773b836d444030f18b5a6940 [diff] |
PLDM Message Structure Change With this change, PLDM code is optimised. The PLDM payload message structure previously consisted of a pointer to the payload message and the payload length, this structure is removed with this commit and the PLDM message structure now has the PLDM header structure and an array of size 1 whose address is the starting byte of message payload. Therefore, pldm msg struct can represent a request/response message in contiguous memory, thereby enabling simple casts and avoiding memcpys to get from a uint8_t* to pldm msg or vice versa. This commit also introduces a change to have the response handlers allocate memory for responses. This is aligned with the message struct change, and enables varying length responses. Change-Id: Ia46d852b8b16bfc7cf04f38435bd4079ad33c66b Signed-off-by: vkaverap <vkaverap@in.ibm.com>
At a high-level, code in this repository belongs to one of the following three components.
This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:
Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.
Given a PLDM command "foo", the library will provide the following API: For the Requester function:
encode_foo_req() - encode a foo request decode_foo_resp() - decode a response to foo
For the Responder function:
decode_foo_req() - decode a foo request encode_foo_resp() - encode a response to foo
The library also provides API to pack and unpack PLDM headers.
This library provides handlers for incoming PLDM request messages. It provides for a registration as well as a plug-in mechanism. The library is implemented in modern C++, and handles OpenBMC's platform specifics.
The handlers are of the form
Response handler(Request payload, size_t payloadLen)
Source files are named according to the PLDM Type, for eg base.[hpp/cpp], fru.[hpp/cpp], etc.
Consider hosting libpldm above in a repo of its own, probably even outside the OpenBMC project? A separate repo would enable something like git submodule.
This section documents important code flow paths.
a) PLDM daemon receives PLDM request message from underlying transport (MCTP).
b) PLDM daemon routes message to message handler, based on the PLDM command.
c) Message handler decodes request payload into various field(s) of the request message. It can make use of a decode_foo_req() API, and doesn't have to perform deserialization of the request payload by itself.
d) Message handler works with the request field(s) and generates response field(s).
e) Message handler prepares a response message. It can make use of an encode_foo_resp() API, and doesn't have to perform the serialization of the response field(s) by itself.
f) The PLDM daemon sends the response message prepared at step e) to the remote PLDM device.
a) A BMC PLDM requester app prepares a PLDM request message. There would be several requester apps (based on functionality/PLDM remote device). Each of them needn't bother with the serialization of request field(s), and can instead make use of an encode_foo_req() API.
b) BMC requester app requests PLDM daemon to send the request message to remote PLDM device.
c) Once the PLDM daemon receives a corresponding response message, it notifies the requester app.
d) The requester app has to work with the response field(s). It can make use of a decode_foo_resp() API to deserialize the response message.