Re: Question about AETH_NAK_PSN_SEQ_ERROR

[Chengguang Xu <cgxu519@mykernel.net>]

在 2022/5/15 0:22, Bob Pearson 写道:
> On 5/14/22 09:20, Chengguang Xu wrote:
>> 在 2022/5/14 21:35, Chengguang Xu 写道:
>>> Hello Folks,
>>>
>>>
>>> There is a logic(below code) in check_ack() in rxe_comp.c,  the case (AETH_NAK_PSN_SEQ_ERROR)
>>> indicates sending side received a nak ack which means opposite side had an psn seq error(expected psn < received psn).
>>> I don't fully understand the comment(/* a nak implicitly acks all packets with psns before */) here,
>>> could someone give me a hint for this?
> For a start go to
>
> https://www.infinibandta.org/ibta-specification/
>
> and follow the directions to get access to the InfiniBand Architecture Specification Vol. 1. It should be
> free but you have to provide contact information. Unless your company is a member of the IBTA.
>
> If you already have access then look at IBA 9.7.5.1.2 Coalesced Acknowledge Messages.
>
> Any response carrying a packet sequence number implicitly acks all request packets with
> a PSN smaller than the one carried in the response packet. It may ack or nak the request packet
> with the same psn.
>
>> Carefully checking rxe_resp.c and found the psn in the ack (with AETH_NAK_PSN_SEQ_ERROR) is resp.psn not received pkt->psn.  :-)
>>
> resp.psn will carry the correct response psn for the current response packet. This will be the same
> as the psn of the req packet for send/write, and atomic requests but will be one of the range
> of psns of a read request response. I.e. if the mtu is 4K and the read is 1MB there will be
> 256 read response packets to reply to the read request with psns starting at the psn of the
> request and increasing by 1 until the message is done. The next request packet must leave a gap of
> 255 psns.

Thank you very much for detailed explanation!

Chengguang