Re: Initial MCTP design proposal

From: Jeremy Kerr <jk@ozlabs.org>
To: Deepak Kodihalli <dkodihal@linux.vnet.ibm.com>,
	openbmc <openbmc@lists.ozlabs.org>
Cc: Emily Shaffer <emilyshaffer@google.com>,
	David Thompson <dthompson@mellanox.com>,
	Dong Wei <Dong.Wei@arm.com>,
	Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>,
	"Naidoo, Nilan" <nilan.naidoo@intel.com>
Subject: Re: Initial MCTP design proposal
Date: Fri, 07 Dec 2018 15:41:49 +0800	[thread overview]
Message-ID: <0836fa0be44c76b7d33115c2c8c834db03b94aad.camel@ozlabs.org> (raw)
In-Reply-To: <94639b69-3f3c-a606-ae68-f7e1461097e9@linux.vnet.ibm.com>

Hi Deepak,

Thanks for the feedback! From your comment:

> > I see two options for the "inbound" or "application" interface of
> > the
> > MCTP daemon:
> > 
> >   - it could handle upper parts of the stack (eg PLDM) directly,
> > through
> >     in-process handlers that register for certain MCTP message
> > types; or
> 
> We'd like to somehow ensure (at least via documentation) that the 
> handlers don't block the MCTP daemon from processing incoming
> traffic. The handlers might anyway end up making IPC calls (via D-Bus) 
> to other processes. The second approach below seems to alleviate this
> problem.

There are two design elements there:

 - requiring that the handlers do not block; and

 - whether the handlers are implemented in-process, or remotely over IPC

and I think that while they're related, the non-blocking-behaviour
doesn't necessarily require either in-process or IPC. As long as we have
the right interfaces, we can make that decision separately.

IUf we use IPC, we'd still need to make sure that the IPC mechanism
doesn't block, so we'd have similar issues either way.

Cheers,

Jeremy