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

[Vernon Mauery]

On 12-Oct-2017 09:25 AM, Xo Wang 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.

What about a ipmi queue library or something that handles loading the 
appropriate provider libraries (based on some path) and then manages the 
incoming messages. We have two separate queue implementations between 
net-ipmi and host-ipmi; we could simplify this so the behavior is the 
same between the two.

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

I will probably start with changes like this that pull me gently into 
the 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).
> 
> I can't immediately think of why a provider might want to respond to a
> command differently based on what host interface it came on, but maybe
> somebody else can.

We have two kcs interfaces that in theory are supposed to have different 
behavior: one is from the host and can have reasonable latency, the 
other is the kcs that the BIOS would use during an SMI and needs to have 
minimal latency. That being said, I am not sure if this feature is still 
used at this time. You said you were looking for a use case. :)

--Vernon