[openib-general] matching an RMPP NACK to send or receive?

[Sean Hefty]

Hal Rosenstock wrote:
>>I'm returning IB_WC_REM_ABORT_ERR and placing the actual RMPP status code in 
>>the vendor_err field.
> 
> What vendor errors are being defined ? I realize that is the only way to
> do this now but aren't they really standard rather than vendor errors ?

No vendor errors are being defined.  I'm simply returning the received RMPP 
Status in that field since it's not used in this case.  We can rename 
vendor_err to something else.

>>I believe that the following status values are possible for either a send or 
>>receive:
>>
>>resources exhausted
>>bad RMPP type
>>illegal status
>>unspecified and class specific
> 
> What's unspecified ? Is it reserved status in ABORT ?

Unspecified is status value 127 - "an error .. not covered by any other 
status code".  This is handled, but only aborts a send request if received.

> There are some others too. Does the OpenIB RMPP not generate them ? Will
> it pass them back up if it received an abort with these other statuses ?

I think that the other status codes occur only in response to a send OR to a 
receive.  So it's not that they're not generated, I just have a better idea 
on how to handle them.

Total time too long - assuming sent by receiver to sender.  This is handled.

Inconsistent last and payload length - sent by receiver to sender.  This is 
not transmitted currently, but should work fine if received.  (I need to add 
state information to transmit this.)

Inconsistent first and segment number - transmitted by receiver to sender. 
This is handled.

Bad RMPP type - transmitted either way.  This is checked for all messages, 
but will only abort a send request if received.

New window last too small - transmitted by sender to receiver.  This is handled.

Segment number too big - transmitted by sender to receiver.  This is handled.

Illegal status - transmitted either way.  This is checked for all messages, 
but will only abort a send request if received.

Unsupported version - transmitted by receiver to sender.  This is handled.

Too many retries - assuming sent by sender to receiver.  This is not 
handled.  (I need to add a new call from the MAD code into the RMPP layer to 
support this.)

- Sean