README: add high level flows
Add requester and responder flows.
Change-Id: I57ef227b1db52b42c9de26a84f1051b2772b6da8
Signed-off-by: Deepak Kodihalli <dkodihal@in.ibm.com>
diff --git a/README.md b/README.md
index 1b93119..22907a8 100644
--- a/README.md
+++ b/README.md
@@ -49,3 +49,32 @@
## TODO
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.
+
+# Flows
+This section documents important code flow paths.
+
+## BMC as PLDM responder
+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.
+
+## BMC as PLDM requester
+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.