[PATCH linux dev-4.7 7/8] ipmi: maintain a request expiry list
Brendan Higgins
brendanhiggins at google.com
Tue Nov 8 06:29:40 AEDT 2016
Patrick, you are correct.
The { Seq, Command, NetFn } set does not necessarily uniquely identify a
message. The the OEM/Group extension messages as defined in the IPMI v2.0
Specification Document Revision 1.1, Section 5.1 Network Function Codes,
Table 5, under the name OEM/Group defines unique message endpoints by the
following set: { NetFn, Payload{0, 1, 2}, Command }; where Payload{0, 1, 2}
are the first three bytes of a message payload.
In addition, I am working on an OEM/Group extension that would allow a
single transaction to take place across multiple messages, and in
particular would allow multiple IPMI requests to be sent, potentially only
sending (a) response(s) at the end of the transaction; in particular, this
would allow the following:
Master | Slave
Request -> |
Request -> |
Request -> |
| <- Response
| <- Response
Where Request and Response have the same sequence number. Note: the change
I am making would also make the above example valid if there were only one
request and two responses.
@Cédric I see two remedies for your patch to allow this:
1) Allow users to opt out of the expiry list.
2) Update the keep alive list when *either* a new request or a new response
is sent with a given sequence number (change the list to be a hashmap of
sequence numbers to timeouts).
I will try to get a design doc for discussion describing this extension out
hopefully sometime this week; I think that might clear some things up.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161107/bfd0c6a6/attachment.html>
More information about the openbmc
mailing list