MCTP over PCI on AST2500

[Jeremy Kerr]

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> 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/a7836420/attachment.htm>