-
Notifications
You must be signed in to change notification settings - Fork 58
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
rdma: add separate bounce buffer freelist for data (eager) messages #614
base: master
Are you sure you want to change the base?
Conversation
19af9ec
to
512366e
Compare
512366e
to
6cbe500
Compare
The CI failure(s) are real:
Need to fix up some asserts. |
6cbe500
to
3494556
Compare
3494556
to
bf176e6
Compare
Rebased on master |
bot:aws:retest |
1 similar comment
bot:aws:retest |
5f22617
to
bb2483a
Compare
Rebase on master |
e5452be
to
7f36f35
Compare
Rebased on master |
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 don't think this is the right approach. Now would be a great time to clean up some code, but this only makes the code more confusing.
Bounce buffers for eager messages and control messages are different things. Have different structures with different names so that there's no reason to figure out what's what. I'm also not sure I understand the desire to move the freelists from the endpoint into the per-rail structures, given that most of the data is really operations that will be per-endpoint.
They are different things, but there is a lot of code that is shared between them (e.g., all of the buffer pool management code, posting receives). We should rename these structures to something more generic (like receive buffers instead of bounce buffers [which I wanted to do in a followup patch]), but I think duplicating all the buffer management code is overkill.
I'm confused... isn't having the freelists per-rail exactly what you were advocating in #614 (comment)? I think it makes sense to have the freelists per-rail because posted recv buffer counts are maintained per-rail. |
I think the problem with your patch is that it's way too much cognitive load to figrue out what a bounce buffer is. And the rest is just too confusing to review. Fix that. |
Converting this to draft until I have cycles to work on feedback above. |
ef38a5b
to
be82b8e
Compare
Force-push fixes the CI issue, and fixes a dormant plugin bug in the process. Force-push is a rebase on #762. |
2ad142f
to
61c8ecf
Compare
61c8ecf
to
9e833ce
Compare
9e833ce
to
eeb3e7d
Compare
The close message was being sent on the data rails instead of the control rail(s). This was a harmless bug today, but needs to be fixed for future changes. Also, consolidate some code between ctrl and close messages to avoid such bugs in the future. Signed-off-by: Eric Raut <eraut@amazon.com>
This will facilitate creating different request types for control and data rail rx buffers. Signed-off-by: Eric Raut <eraut@amazon.com>
eeb3e7d
to
8702014
Compare
These two requst types current share an underlying data structure. Signed-off-by: Eric Raut <eraut@amazon.com>
For default eager max size, ctrl buffers are much smaller than eager buffers. Signed-off-by: Eric Raut <eraut@amazon.com>
8702014
to
ac8a54a
Compare
@@ -1763,7 +1780,7 @@ static inline int process_err_completion(nccl_net_ofi_rdma_device_t *device, | |||
err_entry.prov_errno, | |||
fi_cq_strerror(cq, err_entry.prov_errno, err_entry.err_data, NULL, 0), | |||
(long)err_entry.len, nccl_net_ofi_req_str(req)); | |||
if (req->type == NCCL_OFI_RDMA_RX_BUFF) { | |||
if (req->type == NCCL_OFI_RDMA_CTRL_RX_BUFF || NCCL_OFI_RDMA_EAGER_RX_BUFF) { |
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.
This is treating the enum value like a boolean, which will end up being true. This should be (req->type == NCCL_OFI_RDMA_CTRL_RX_BUFF || req->type == NCCL_OFI_RDMA_EAGER_RX_BUFF)
Separate out bounce buffer freelists into a smaller-sized freelist for
control messages and a larger size for data (eager) messages
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.