Question about AETH_NAK_PSN_SEQ_ERROR

Question about AETH_NAK_PSN_SEQ_ERROR

[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?

Also, set qp->comp.psn as pkt->psn will skip some psns(from qp->comp.psn 
to pkt->psn) in the retry, is it correct?

Many thanks in advance!
Chengguang

-------------------------

   case AETH_NAK:
             switch (syn) {
             case AETH_NAK_PSN_SEQ_ERROR:
                 /* a nak implicitly acks all packets with psns
                  * before
                  */
                 if (psn_compare(pkt->psn, qp->comp.psn) > 0) {
                     rxe_counter_inc(rxe,
                             RXE_CNT_RCV_SEQ_ERR);
                     qp->comp.psn = pkt->psn;
                     if (qp->req.wait_psn) {
                         qp->req.wait_psn = 0;
                         rxe_run_task(&qp->req.task, 0);
                     }
                 }
                 return COMPST_ERROR_RETRY;

Re: Question about AETH_NAK_PSN_SEQ_ERROR

[Chengguang Xu]

在 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?

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



>
> Also, set qp->comp.psn as pkt->psn will skip some psns(from 
> qp->comp.psn to pkt->psn) in the retry, is it correct?
>
> Many thanks in advance!
> Chengguang
>
> -------------------------
>
>   case AETH_NAK:
>             switch (syn) {
>             case AETH_NAK_PSN_SEQ_ERROR:
>                 /* a nak implicitly acks all packets with psns
>                  * before
>                  */
>                 if (psn_compare(pkt->psn, qp->comp.psn) > 0) {
>                     rxe_counter_inc(rxe,
>                             RXE_CNT_RCV_SEQ_ERR);
>                     qp->comp.psn = pkt->psn;
>                     if (qp->req.wait_psn) {
>                         qp->req.wait_psn = 0;
>                         rxe_run_task(&qp->req.task, 0);
>                     }
>                 }
>                 return COMPST_ERROR_RETRY;
>
>
>

Re: Question about AETH_NAK_PSN_SEQ_ERROR

[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.
> 
> 
>>
>> Also, set qp->comp.psn as pkt->psn will skip some psns(from qp->comp.psn to pkt->psn) in the retry, is it correct?
>>
>> Many thanks in advance!
>> Chengguang
>>
>> -------------------------
>>
>>   case AETH_NAK:
>>             switch (syn) {
>>             case AETH_NAK_PSN_SEQ_ERROR:
>>                 /* a nak implicitly acks all packets with psns
>>                  * before
>>                  */
>>                 if (psn_compare(pkt->psn, qp->comp.psn) > 0) {
>>                     rxe_counter_inc(rxe,
>>                             RXE_CNT_RCV_SEQ_ERR);
>>                     qp->comp.psn = pkt->psn;
>>                     if (qp->req.wait_psn) {
>>                         qp->req.wait_psn = 0;
>>                         rxe_run_task(&qp->req.task, 0);
>>                     }
>>                 }
>>                 return COMPST_ERROR_RETRY;
>>
>>
>>
> 
> 

Re: Question about AETH_NAK_PSN_SEQ_ERROR

[Chengguang Xu]

在 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