[LU-12569] IBLND_CREDITS_HIGHWATER does not check connection queue depth Created: 21/Jul/19 Updated: 23/May/22 Resolved: 20/Sep/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.13.0, Lustre 2.12.3 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Patrick Farrell (Inactive) | Assignee: | Amir Shehata (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Severity: | 3 | ||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
The IBLND_CREDITS_HIGHWATER check is used to decide at what # of credits a NOOP message needs to be sent in order to return credits (this is for the case when we send many immediate messages, which consume credits but do not get an acknowledgment, so their credits are not automatically returned). However, the check uses a global tunable: lnd_peercredits_hiw This tunable is checked against the global peer credits value to make sure it is sane (see kiblnd_tunables_setup()), which is to say that it is less than the total number of credits. However, individual connections can have a different queue depth than the global setting (total credits for a connection is equal to the connection queue depth). That means if a connection queue depth differs (See particularly kiblnd_create_conn(), the "queue depth reduced" warning message for one case where this can happen) from the global value, it is possible for the highwater mark to be higher than the total number of credits. In this case, no NOOP messages will be sent, and it is possible to stall out a connection if both sides send many immediate messages at once. Essentially, if both ends of a connection send enough immediate messages to exhaust credits, then neither side will send any more messages. The high water mark is supposed to prevent this by having them send a NOOP before they reach this state. But if the highwater mark is greater than the number of credits, this will not occur, and the connection will stall out until a ping or other event causes credits to be returned. The solution should be simple - The highwater mark check needs to take in to account the queue depth of an individual connection. |
| Comments |
| Comment by Gerrit Updater [ 21/Jul/19 ] |
|
Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35578 |
| Comment by Patrick Farrell (Inactive) [ 21/Jul/19 ] |
|
It's probably possible to write a test for this, but I'm not really an IB guy. The tricky part is getting all the messages in flight at once. We could probably delay receipt? On both sides of the connection, though. So: Then send a bunch of immediate messages from both sides, which will exhaust the credits. The other aspect of this is, if we want to trigger this specific issue, we have to engineer a reduced queue depth. That normally happens as part of this: while (rc); Or possibly just reducing queue depth as a hack would work - Just reduce it by using a fail_loc here, |
| Comment by Patrick Farrell (Inactive) [ 16/Aug/19 ] |
|
Amir is planning to rework this one as part of fixing |
| Comment by Gerrit Updater [ 20/Sep/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35578/ |
| Comment by Peter Jones [ 20/Sep/19 ] |
|
Landed for 2.13 |
| Comment by Gerrit Updater [ 21/Sep/19 ] |
|
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36254 |
| Comment by Gerrit Updater [ 28/Sep/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36254/ |