phosphor-host-ipmid and phosphor-net-ipmid architecture

[Brad Bishop]

> On Oct 12, 2017, at 12:25 PM, Xo Wang <xow at google.com> wrote:
> 
> On Thu, Oct 12, 2017 at 9:03 AM, Brad Bishop
> <bradleyb at fuzziesquirrel.com> wrote:
>> 
>>> On Oct 11, 2017, at 6:05 PM, Vernon Mauery <vernon.mauery at linux.intel.com> wrote:
>>> 
>>> I am working on an ipmi provider library and had a few questions and
>>> observations.
>>> 
>>> 1) Why are there separate ipmi message queues for the host and network?
>> 
>> iirc it was so that you could have a different set of providers
>> registered for each channel or even different, channel specific
>> implementations for the same command.
>> 
> 
> The reasoning here also derives from the "build the distro as you like
> it" approach. If you don't want a network interface to the BMC, then
> you can simply not build it or its handlers.
> 
> Of course we could write a single queue service for both host and
> network that can be configured and built to support only one, but that
> puts the onus on architecting and testing that service to ensure the
> all three configurations all work independently.

Another possible advantage for multiple queues might be cgroups prioritization.

> 
>>>  It seems awkward that for the host, the ipmi request comes from a
>>>  different process (btbridge, or in our case kcsbridge), while for the
>>>  network (RMCP+), the messages are handled directly in the same
>>>  process.
>> 
>> Is it still awkward if you accept the two queue approach?  The
>> additional layer is needed for the bt/kcs -> host-ipmid
>> abstraction.  No such abstraction is needed for network.
>> 
>>> 
>>>  It seems that the network handler could just as easily package the
>>>  command up and send it to ipmid the same way that btbridge does.
>>> 
>>> 2) Can we modify the signature of the handlers so that they can behave
>>>  in a more intelligent manner? It would be nice if they were handed a
>>>  gsl::span<uint8_t> instead of a void* and a length. This allows for
>>>  a no-copy, bounds-checked way of passing buffers.
>> 
>> sounds good to me!
>> 
> 
> We can use more intelligent (safer) data passing throughout phosphor code. :)
> 
>>> 
>>>  It would be nice to know what channel something came in on. We might
>>>  want to be able to change behavior based on the incoming channel (as
>>>  some channels are more secure than others).
>> 
>> I think the separate message queues solves this need; however, doing
>> this need not be mutually exclusive of having separate queues if that
>> enables another use case we don’t support today.
>> 
>> I’m not totally stuck on two queues.  Especially if some alternative
>> maintains the same level of flexibility.  The motivation for a single
>> queue isn’t clear yet to me though - without more discussion it sounds
>> like we’d end up with the same capability we already have…so why bother?
>> 
> 
> One set of cases is where a host might have multiple interfaces to the
> BMC (e.g. BT and SSIF).

What about three queues here?  (bt, ssif and rmcp)?  It would require
some rework of the bt/ssif/kcs -> host-ipmid interface to support multiple
host-ipmid instances.