Re: Question about NVMe MCTP in dbus-sensors

[Heyi Guo <guoheyi@linux.alibaba.com>]

Hi Andrew,


On 2021/8/6 下午1:42, Andrew Jeffery wrote:
> 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.

Could you point out where I can find these forks, including libmctp and 
kernel? So that we can do some initial test with the current 
implementation of NVMeSensor in dbus-sensors.

Thanks,

Heyi


>
> 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