[PATCH linux dev-4.7 7/8] ipmi: maintain a request expiry list

[Cédric Le Goater]

Hello Brendan,

On 11/07/2016 08:29 PM, Brendan Higgins wrote:
> 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.

OK. I missed that part. I was referring to : 

  11.1 BT Interface-BMC Request Message Format

    ...
    The Seq field is used in combination with the NetFn and Command fields to 
    form a unique value. I.e. the same Seq value could be used in multiple 
    outstanding requests, as long as the combinations of Seq value, NetFn, 
    and Command were unique among the requests.
    ...
and

  11.3 Using the Seq Field
  11.4 Response Expiration Handling

    ...
    The BMC can define its own internal Seq value or tracking number for
    this purpose, or it could use the Seq, NetFn, and Command values in the
    same manner as SMS.
    ...

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

I am wondering how that fits with the BT Interface Capabilities which can 
recommend retries.

> @Cédric I see two remedies for your patch to allow this:
> 
> 1) Allow users to opt out of the expiry list.

yes that's should not be too hard.

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

The BMC driver could also define its own 'Seq' identifier (using the tuple 
above) to do the request/response matching instead of using the 'Seq' byte.

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

OK but we should be having this discussion on :
 
	openipmi-developer at lists.sourceforge.net

where the patches are being discussed. Corey would have some very valuable
input. Could you join that thread ? 

	http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/465131.html
	
Or I can copy you, it might be easier and then you can start another thread
with your design.

Thanks!

C.