[EXTERNAL] Re: nvme sensors

[Andrew Jeffery]

On Thu, 16 Apr 2020, at 17:22, Neeraj Ladkani wrote:
> Some of use cases:
> 
> - Standard MCTP message handling

This can be split into a few parts:

1. MCTP binding implementations
2. MCTP message packetisation
3. APIs to expose the control commands defined in the DSP0236

Regarding 1, we have a couple of bindings in upstream libmctp:

a. The standard serial binding (DSP0253)
b. A vendor-defined (IBM) LPC binding (i.e. this is not the standard KCS binding).

As mentioned elsewhere in this thread Intel have a lot of out-of-tree code that
enables the SMBus binding. Some of the difficulties with upstreaming this code
are addressed by moving MCTP into the kernel and exposing a socket interface.

Regarding 2, this is already reasonably well handled by libmctp.

Regarding 3, I'm working through some of the details with Richard and Sumanth
from Intel at the moment about how we best support the base control commands
and the effects they can have on binding instances in libmctp. One of the issues
to highlight here is the split between in-band data and out-of-band notifications.
Currently libmctp's mctp-demux-daemon does not have a good story around
out-of-band notifications.

Regarding the planned kernel implementation, 1 and 2 will happen in-kernel,
while 3 will remain in userspace. The plan is to implement a netlink interface
to control configuration of the MCTP network, which will allow userspace to
communicate out-of-band data from the standard commands to the kernel.

> - MCTP bridging 

There is some support in libmctp for bridging but it would currently require
an application to explicitly exploit it. For instance it's not exploited by the
mctp-demux-daemon (in utils/).

Supporting MCTP bridging is definitely on my radar for the kernel implementation.

> - Support SMBUS ( PCIe in future) 

The motivation behind the kernel implementation is to hide the specifics of
applying a binding specification to a piece of hardware from userspace, which
removes the currently problem of needing to create bespoke userspace
interfaces to expose the hardware capabilities out to userspace. Once I have
the in-kernel interfaces going for MCTP then adding support for SMBus and
PCIe bindings should be the same amount of effort as implementing a device
driver.

> - MCTP tool( from console) that can be used to send any MCTP messages 
> to a device and read responses, discovery etc.

Yep, I intend to write one as part of supporting the kernel implementation.
This would be usable with the socket interface provided by the
mctp-demux-daemon.

> 
> Can you explain what are problems with libmctp(SMBUS binding ) with 
> current implementation?

That might best be left to the Intel people who have already done some work
in this area.

Thanks for the response. Hope my replies help.

Andrew