Yes Jeremy. We are aware about the limitation, but as Sharad stated, we will be starting with D-Bus based approach, due to priority ( and then move to socket based approach, at-least not immediately). Having said that pushed a WIP document for both MCTP & PLDM (still in high level, and low level implementation details capturing are in progress). We can further discuss in the review (for better tracking). 1. https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/28424/ 2. https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/28425/ Note: Proposal is to have a abstraction layer between D-Bus & Socket, so that upper layers like PLDM can switch to socket-driver based approach at later stage. Related to MCTP over PCIe Iowna will send out a review which will be along the MCTP base design document. Regards, Richard On 1/14/2020 12:09 PM, Khetan, Sharad wrote: > Thanks for the pointer Jeremy. We will look into demux daemon. > Thanks, > -Sharad > > On Jan 13, 2020, at 10:21 PM, Jeremy Kerr > wrote: > >> Hi Ketan, >> >> Just a suggestion - you probably don't want to be passing MCTP >> messages over dbus - this is something we learnt from the IPMI >> implementation. >> >> The current design of the mctp-demux-daemon (included in the libmctp >> codebase) is intended to provide an interface that will be easy to >> migrate to a future kernel implementation (ie., using sockets to pass >> MCTP messages), and allows multiple applications to be listening for >> MCTP messages of different types. >> >> Regards, >> >> >> Jeremy >> >> On 14 January 2020 1:54:49 pm AWST, "Khetan, Sharad" >> > wrote: >> >> Hi Deepak, >> >> On 13/01/20 10:23 PM, Khetan, Sharad wrote: >> >> Hi Andrew, On Thu, 9 Jan 2020, at 12:27, Andrew Jeffery wrote: >> >> On Sat, 21 Dec 2019, at 10:45, Khetan, Sharad wrote: >> >> Hi Andrew, Sorry for late response. The plan is to >> have MCTP in user space. >> >> How are you handling this then? mmap()'ing the BAR from >> sysfs? >> >> Sorry, let me put my brain back in, I was thinking of the >> wrong side of the BMC/Host MCTP channel. How much were >> you planning to do in userspace on the BMC? As in, are >> you planning to drive the BMC's PCIe MCTP controller from >> userspace (presumably via /dev/mem)? >> >> For implementation on the BMC, we agree that it's better to >> do it in kernel (and as you mentioned - use consistent >> interface to upper layers, provide another transport). >> However, given the time needed to implement things in kernel >> (and the review after), we are starting with a short term >> solution. We will be implementing MCTP (protocol elements) in >> user space, along with a low level MCTP PCIe driver just to >> push bits on PCIe. Iwona is working on this and should be >> able to describe the exact primitive. >> >> >> Do you plan to do the user-space work as an extension to/reusing components from openbmc/libmctp? >> >> Thanks, >> Deepak >> >> Yes we plan to reuse and extend the libmctp, support PCIe as well as SMBus bindings. We plan to use d-bus extensions to existing libmctp. That said, we will know the exact extent of reuse/modifications when we really start implementing. >> >> We are implementing this for AST 2600 (will not support any workarounds for AST 2500 bug). >> >> @Andrew, Thanks for your response. >> >> Thanks, >> Sharad >> >>