Skip to content

Process pending_close_binds unconditionally in evpl_continue#38

Open
benjarvis wants to merge 1 commit intomainfrom
fix/pending-close-binds
Open

Process pending_close_binds unconditionally in evpl_continue#38
benjarvis wants to merge 1 commit intomainfrom
fix/pending-close-binds

Conversation

@benjarvis
Copy link
Copy Markdown
Member

Summary

  • Binds pending close were only cleaned up when evpl_core_wait() returned 0 (no events)
  • Under sustained load this condition may never be met, causing pending close binds to accumulate indefinitely and preventing connections from being fully torn down
  • Now processes pending_close_binds on every iteration of evpl_continue() regardless of event count

Previously, binds pending close were only cleaned up when
evpl_core_wait() returned 0 (no events). Under sustained load this
condition may never be met, causing pending close binds to accumulate
indefinitely and preventing connections from being fully torn down.

Process pending_close_binds on every iteration regardless of whether
events were returned.
@benjarvis benjarvis force-pushed the fix/pending-close-binds branch from 18fb319 to f0a9ab8 Compare February 7, 2026 14:54
@benjarvis
Copy link
Copy Markdown
Member Author

Going to let this one lie for a bit. I have doubts because the reason for this logic in the first place is that the verbs RDMA stack can return events for an RDMA QP even after it has been disconnected, so we need a deferment of the final teardown of the bind related structures to ensure that any events we might receive about them have been received.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant