MCTP over PCI on AST2500

[Thomaiyar, Richard Marian]

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 <jk at ozlabs.org 
> <mailto:jk at ozlabs.org>> 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" 
>> <sharad.khetan at intel.com <mailto:sharad.khetan at intel.com>> 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
>>       
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200114/6aac8a3d/attachment.htm>