Re: MCTP over PCI on AST2500

["Andrew Jeffery" <andrew@aj.id.au>]

Hi Richard,

On Fri, 10 Jan 2020, at 07:15, Richard Hanley wrote:
> I'll add a +1 in interest for MCTP.
> 
> Performance would be better if this is moved to the kernel, but I'm a 
> bit curious about any other pros and cons of working in userspace.
> 
> One of our most immediate use cases for MCTP would be in a UEFI BIOS 
> before a Redfish client can be bootstrapped. Would things be more 
> portable for BIOS vendors if this is done in userspace. I genuinely 
> don't know enough about that area to know which is more flexible.

As MCTP is just a transport it has a fairly well-contained set of behaviours
(by contrast, see PLDM). The idea of implementing MCTP in the kernel isn't
really about performance so much as providing a consistent, binding-
independent interface to userspace. The advantage here is that as the
bindings would also be implemented in-kernel we avoid creating bespoke
interfaces to plumb binding-specific behaviours out to userspace just to
hook into e.g. libmctp. This should lead to less friction getting patches
adding support for new bindings merged upstream (at the cost of getting
an MCTP subsystem into the kernel).

The proposal is to add a new socket address family, AF_MCTP. A number of
MCTP concepts map fairly neatly onto existing networking concepts - it's a
packet-switched network routing data between components inside the
platform over heterogeneous bus types. The approach is somewhat inspired
by AF_CAN for CAN bus. libmctp already prepares its consumers for a socket-
based interface with the demux daemon, so existing consumers would only
need a small change to switch to the kernel-based socket interface.

I've written a little more about it all in the past:

https://lists.ozlabs.org/pipermail/openbmc/2019-May/016460.html

Hope that helps!

Andrew