-
Notifications
You must be signed in to change notification settings - Fork 901
pml/ob1: match callback will now queue wrong sequence frag and return. #4419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in order to keep the PERUSE API functional please add before the append_frag_to_list
/**
* We generate the MSG_ARRIVED event as soon as the PML is aware of a matching
* fragment arrival. Independing if it is received on the correct order or not.
* This will allow the tools to figure out if the messages are not received in the
* correct order (if multiple network interfaces).
*/
PERUSE_TRACE_MSG_EVENT(PERUSE_COMM_MSG_ARRIVED, comm_ptr,
hdr->hdr_src, hdr->hdr_tag, PERUSE_RECV);
In multithreaded case, it is expensive to release the lock, call the slow match and retake the lock again just to queue the frag. This patch will eliminate number of lock taken by queueing the frag right away and return. Signed-off-by: Thananon Patinyasakdikul <[email protected]>
adjusted the commit per @bosilca comment. |
Added a patch from @bosilca to put incoming out of sequence fragments into an ordered list to minimize the searching time. |
All Tests Passed! |
Rework the logic to handle the out-of-sequence fragments on the receiver side. A large number of OOS messages are still arriving even in single threaded scenarios. Signed-off-by: George Bosilca <[email protected]>
@thananon @bosilca This PR resulted in 2 serious-looking Coverity warnings:
|
Thanks @jsquyres , both can be safely ignored, the design is meant that way. If you look at the comment right next to CID 1420943, there is a comment about this. |
Cool; thanks @bosilca |
In multithreaded case, it is expensive to release the lock, call the slow match
and retake the lock again just to queue the frag. This patch will eliminate number of
lock taken by queueing the frag right away and return.
Also, when the message arrive out of order, we queue it up in an ordered list to minimize the searching time.
@bosilca please review.