Supporting one IPMI request does not yield one response

[Patrick Williams]

On Sat, Sep 10, 2016 at 01:02:02AM +0000, Brendan Higgins wrote:
> Hello,
> The reason I am interested in having support for not requiring one response
> to be tied to one request is because I am interested in multiple responses
> being associated with a single request. In particular, I am interested
> adding an OEM Group extension that allows arbitrarily large payloads to be
> broken up across multiple Block Transfer messages.
> 
> I have a prototype for this OEM Group extension that I have tested on the
> Aspeed 2500 EVB; there are some changes that need to be made to the handler
> code in phosphor-host-ipmid to make it work, but nothing that seemed to
> have any potential for controversy other than allowing a single request to
> solicit none-to-many responses. There are other ways to make this work, but
> this seemed to be the most palatable to me for the reason that it generates
> less traffic than having to send a dummy request to get each of the
> responses after the first one or using something like SMS Attention. I also
> thought that the OpenBMC community might find supporting one request
> soliciting multiple responses to be interesting because it would add the
> capability to support IPMI Message Bridging as it requires sending two
> responses for a single request (see '6.13.4 Bridged Request Example' in the
> IPMI spec).
> 
> The OEM Group extension I mentioned could be thought of as a transport
> layer over IPMI; it is something that I would like to get some more
> feedback on later at which time I will send a more specific email detailing
> how it works. Right now, I am just interested in whether there is any
> interested in allowing a single IPMI request to solicit none-to-many
> responses.
> 
> Feedback is greatly appreciated!
> 
> Thanks!

Brendan,

I don't see anything wrong with doing an enhancement so we can support
0-N response messages.  I could see that being beneficial for both
directions on some of the larger messages we have, such as inventory and
oem-esel.

In addition to host-ipmid, you would need to enhance bt-bridged to
recognize that there is a continuation to the message.  I think we would
want host-ipmid to always indicate to bt-bridged even in the 0-response
case, so that bt-bridge can properly clean up its timeout states.  (We
don't want the knowledge in bt-bridged to interpret the IPMI message to
know it is a continued one, unless it is simple and standard).

Is this something you'd be adding support for on the host-firmware side
as well?  I do know the current openpower firmware would not be able to
handle it.

We usually advertise to the host support for something like this via the
capabilities exchange.  Would we need to support a fall-back mode or
would lack of host support just mean that whole classes of IPMI messages
are disabled?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160913/3d393a4e/attachment.sig>