MCTP control messages handling in libmctp

MCTP control messages handling in libmctp

[Wiktor Gołgowski]

Hi all, 



I am currently working on a base implementation for handling control

command requests in libmctp (relevant change here: [1]).  As I am not

sure which solution would be the best here, I would like to put a

quick summary of the different approaches that could be used for

further discussion on Monday PMCI WG meeting:



1. External handling (as Andrew proposes)

All control messages are handled in the layer calling into

libmctp. The daemon is in control of how messages are handled.



2. Separate handlers (what [1] introduces)

There are separate callbacks for regular messages, control messages and

transport-specific control messages. The main reason for this behavior

is that I expect transport-specific commands to be executed in the

context of the specific binding (serial, VDM, SMBus). I also hope that

the daemon could be at least partially binding-agnostic.



3. Handling is split between the caller and the library

We could identify control command requests that libmctp (or its

specific binding) is able to fulfill independently from the daemon

(for example Get EID) and leave the implementation of the rest to the

actual caller.



I hope we could find the best solution to implement. Looking forward

to the Monday meeting.



Regards-

Wiktor





[1] https://gerrit.openbmc-project.xyz/c/openbmc/libmctp/+/30330

Re: MCTP control messages handling in libmctp

[Andrew Jeffery]

Just reply as a note to say this is resolved.

On Sat, 21 Mar 2020, at 04:51, Wiktor Gołgowski wrote:
> Hi all, 
> 
> 
> 
> I am currently working on a base implementation for handling control
> 
> command requests in libmctp (relevant change here: [1]).  As I am not
> 
> sure which solution would be the best here, I would like to put a
> 
> quick summary of the different approaches that could be used for
> 
> further discussion on Monday PMCI WG meeting:
> 
> 
> 
> 1. External handling (as Andrew proposes)
> 
> All control messages are handled in the layer calling into
> 
> libmctp. The daemon is in control of how messages are handled.

After further thought the approach I was suggesting isn't viable,
mainly due to transport-specific commands. It would require violating
abstractions or abusing the routing table to push the messages back
down the stack (the latter being racy).

> 
> 
> 
> 2. Separate handlers (what [1] introduces)
> 
> There are separate callbacks for regular messages, control messages and
> 
> transport-specific control messages. The main reason for this behavior
> 
> is that I expect transport-specific commands to be executed in the
> 
> context of the specific binding (serial, VDM, SMBus). I also hope that
> 
> the daemon could be at least partially binding-agnostic.

This is the route we'll go. It's optional to install a control message handler
into the context, so a daemon could receive all control messages by default
by just doing nothing.

> 
> 
> 
> 3. Handling is split between the caller and the library
> 
> We could identify control command requests that libmctp (or its
> 
> specific binding) is able to fulfill independently from the daemon
> 
> (for example Get EID) and leave the implementation of the rest to the
> 
> actual caller.

We can achieve this with the suggestion in 2. if the installed callback
is structured correctly.

Thanks for posting the summary Wiktor.

Andrew