...
The underlying assumption in the connection management algorithm is that both sides are exchanging messages. If there is a change in the call flow where one side simply sends events with the other side not responding using IMMEDIATE messages, the initiating side will run out of credits and will be stuck since none of the credits are being returned.
It might be better to return the credit on an IMMEDIATE message once the tx is completed. When receiving immediate message do not increment ibc_outstanding_creditsThat's why we have the NOOP message. The intent is to monitor the outstanding credits on the connection and once they pass the peer_credits_hiw mark, then the NOOP message eagerly returns the credits to the other side of the connection to allow it to continue sending.
Queue Depth Negotiation
Queue depth is negotiated as follows:
- active creates its qp and sends it's queue depth to the passive
- passive creates its end of the qp and then sends back its own queue depth which should be <= of the active's
- active receive's the passive's queue depth and sets that to the connection queue depth and credits. Now both ends have the same queue depth and starting credits.
Patch https://review.whamcloud.com/#/c/28850/5 leverages 017d328fa832697533e4e032fe9a9213ea105320 LU-10213 lnd: calculate qp max_send_wrs properly leverages this algorithm by decreasing the active's queue depth when attempting to create the qp, then sending the adjusted queue depth to the passive. The passive creates its connection structure and reduces the queue depth if necessary, then sends it back to the active, which uses that as the connection queue depth and credits.
...