prov/efa: rx_entry allocation failure handling in rxr_pkt_handle_longcts_rtw_recv()

[gestionlin]

Hi, I am studying the implemtation of efa_rdm_protocol_v4 in efa provider. I have some question below:
When a requestor send a LONGCTS_RTR packet to a responder, the responder will try to allocate a rx_entry according to the LONGCTS_RTR packet, but the allocation of rx_entry may fail, the handling of the failure seems to log a error and report an eq error to this upper layer? see rxr_pkt_handle_longcts_rtw_recv(). And the requestor is not notified of the error, it seems the tx_entry for the LONGCTS_RTR in the requestor will be stuck untill the EP is freed?

Thanks.

[wzamazon]

When a requestor send a LONGCTS_RTR packet to a responder,

I think you meant LONGCTS_RTW.

And the requestor is not notified of the error, it seems the tx_entry for the LONGCTS_RTR in the requestor will be stuck untill the EP is freed?

Yes. That is what will happen if rx_entry allocation failed. Unfortunately, the protocol v4 did not define the error handling behavior.

Are you experiencing this issue of rx_entry allocation failure?

[gestionlin]

When a requestor send a LONGCTS_RTR packet to a responder,

I think you meant LONGCTS_RTW.

Yes, the handling function for LONGCTS_RTR should be rxr_pkt_handle_rtr_recv() instead of rxr_pkt_handle_longcts_rtw_recv().
But I think LONGCTS_RTW also have a similar problem, I just use LONGCTS_RTR as an exmple.

And the requestor is not notified of the error, it seems the tx_entry for the LONGCTS_RTR in the requestor will be stuck untill the EP is freed?

Yes. That is what will happen if rx_entry allocation failed. Unfortunately, the protocol v4 did not define the error handling behavior.

I am not sure if it need to be defined in the protocol how this should be handled or how to avoid this.
it seems the implemtentor have no other way but to time out the tx_entry in requestor side？

Are you experiencing this issue of rx_entry allocation failure?

Not yet, but it theoretically happens when the system is under memory pressure.
Also requestors may send a lot of requests maliciously to play DDOS attach?

[wzamazon]

Not yet, but it theoretically happens when the system is under memory pressure.

Yes.

Also requestors may send a lot of requests maliciously to play DDOS attach?

In theory, yes. Note that EFA traffic are limited in one AWS availability zone, so there can only be limited number of requesters.

[gestionlin]

In theory, yes. Note that EFA traffic are limited in one AWS availability zone, so there can only be limited number of requesters.

Even so, this issue still need fixing, right?

I wonder why the responder does not send a NACK to the requestor? So that the requestor can release the tx_entry and report error to the user? If the sending of NACK fails, there should be a timeout in the requestor?