<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
Thanks for the pointer Jeremy. We will look into demux daemon. <br>
Thanks,<br>
<div dir="ltr" id="AppleMailSignature">-Sharad</div>
<div dir="ltr"><br>
On Jan 13, 2020, at 10:21 PM, Jeremy Kerr <<a href="mailto:jk@ozlabs.org">jk@ozlabs.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Ketan,<br>
<br>
Just a suggestion - you probably don't want to be passing MCTP messages over dbus - this is something we learnt from the IPMI implementation.<br>
<br>
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.<br>
<br>
Regards,<br>
<br>
<br>
Jeremy<br>
<br>
<div class="gmail_quote">On 14 January 2020 1:54:49 pm AWST, "Khetan, Sharad" <<a href="mailto:sharad.khetan@intel.com">sharad.khetan@intel.com</a>> wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi Deepak,<br><br>On 13/01/20 10:23 PM, Khetan, Sharad wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi Andrew,<br><br>On Thu, 9 Jan 2020, at 12:27, Andrew Jeffery wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><br><br> On Sat, 21 Dec 2019, at 10:45, Khetan, Sharad wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> Hi Andrew,<br> Sorry for late response.<br> The plan is to have MCTP in user space.<br><br></blockquote><br> How are you handling this then? mmap()'ing the BAR from sysfs?<br></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">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)?<br></blockquote><br>  <br>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.<br></blockquote><br>Do you plan to do the user-space work as an extension to/reusing components from openbmc/libmctp?<br><br>Thanks,<br>Deepak<br><br>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.<br><br>We are implementing this for AST 2600 (will not support any workarounds for AST 2500 bug). <br><br>@Andrew, Thanks for your response.<br><br>Thanks,<br>Sharad<br> <br></pre>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>