-
Notifications
You must be signed in to change notification settings - Fork 932
PML/UCX: reset converter stack on unordered messages #5175
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
PML/UCX: reset converter stack on unordered messages #5175
Conversation
Signed-off-by: Sergey Oblomov <[email protected]>
34c82c7 to
7c5de01
Compare
Signed-off-by: Sergey Oblomov <[email protected]>
04824c5 to
19607da
Compare
|
@bosilca can you pls take a look? |
bosilca
left a comment
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.
I have a question about threading. As you keep the offset in the ucx_datatype how are you ensuring that if multiple threads unpack data in same time they do not collide on the use (and update) of the offset field?
ompi/mca/pml/ucx/pml_ucx_datatype.c
Outdated
| /* permanently switch to un-ordered mode */ | ||
| convertor->offset = 0; | ||
| } else { | ||
| opal_convertor_set_position(&convertor->opal_conv, &offset); |
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.
If you are here the convertor is already set at the right position, so the call to opal_convertor_set_position is unnecessary.
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.
@bosilca fixed
|
UCX receives data in single thread only (even for cases out-of-order/multi-rail mode) |
Signed-off-by: Sergey Oblomov <[email protected]>
bc3d9b3 to
5ec2691
Compare
|
@hoopoepg pls pick to v3.1.x |
fix for openucx/ucx#2568