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

[Vernon Mauery]

On 12-Oct-2017 12:37 PM, Brad Bishop wrote:
> 
> > 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.

I think multiple queues might work out fine then. They do seem to have 
some compelling advantages. But I would like to at least consolidate the 
queueing portion of the code so all the queues have the same bugs.

> >>>  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. 

I think we could have as many queues as we want. I would vote for one 
per interface so that the interface information can be passed in via the 
context data to the handler.

--Vernon