Question about NVMe MCTP in dbus-sensors

[Andrew Jeffery]

Hello Heyi!

On Fri, 6 Aug 2021, at 14:47, Heyi Guo wrote:
> Hi,
> 
> We can see that NVMe sensors in dbus-sensors relies on MCTP to get 
> hardware information. It is using libmctp interfaces to initialize MCTP 
> and SMBus. 

To be clear, it's using a fork of libmctp that implements an SMBus 
binding via a fork of the kernel that exposes a I2C API that isn't 
upstream.

For the SMBus binding to be merged in upstream libmctp I'd like to see 
the necessary kernel interfaces merged into the upstream kernel tree, 
but I don't expect that's going to happen any time soon. More on why 
below.

As an aside you may be interested in this patch which allows nvmesensor 
to use the basic management command to fetch temperature data:

https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/43665

> However I don't find the code or component who is responsible 
> as a bus owner, to discover endpoints, manager EID and update routing 
> table. Isn't necessary for a central component to do such things?

It's not strictly necessary in that it's valid for systems to be 
completely defined in terms of static endpoints. Doing so isn't covered 
by the MCTP spec, and it's also pretty limiting, but it is enough in 
some circumstances.

> Will 
> there be access conflict if non-NVMe devices (MCTP capable) are also 
> connected to the same SMBus？

No.

> 
> We also found another implementation from Intel: 
> https://github.com/Intel-BMC/pmci. It implements mctpd to provide MCTP 
> message transfer interfaces on D-Bus, while PLDM, NVME-MI and others can 
> rely on the D-Bus interfaces instead of libmctp.

This is a direction Intel chose to go however it's not the direction 
that upstream OpenBMC will be using. The use of a pure userspace 
solution such as libmctp went far enough to expose the need for a 
kernel-based solution. We will shortly have that, thanks to the efforts 
of Jeremy and Matt at Code Construct:

https://lore.kernel.org/netdev/20210729022053.134453-1-jk@codeconstruct.com.au/

This series is now in net-next, and Matt and Jeremy have also been 
developing the in-kernel hardware binding support and necessary 
userspace components[1].

[1] https://github.com/CodeConstruct/mctp

You can read more about the application of the socket syscalls here:

https://lore.kernel.org/netdev/20210729022053.134453-16-jk@codeconstruct.com.au/

and here:

https://github.com/openbmc/docs/blob/master/designs/mctp/mctp-kernel.md

Once we have AF_MCTP in the OpenBMC kernel tree with some binding 
implementations we'll be switching the userspace applications over to 
use it.

Hope that helps!

Andrew