Skip to content
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

"correct 2-sided splitting implementation" #1

Open
yiwenzhang92 opened this issue Feb 28, 2018 · 0 comments
Open

"correct 2-sided splitting implementation" #1

yiwenzhang92 opened this issue Feb 28, 2018 · 0 comments

Comments

@yiwenzhang92
Copy link
Member

yiwenzhang92 commented Feb 28, 2018

Making 2-sided splitting work in the correct way might seem harder than it sounds. When the application is using 2-sided verbs in an aggressive way (e.g., posting and polling in separate threads; plus doing sending and receiving at the same time), careful design is required. Why?
(1) How to make sure the flow control message does not collide when the application is doing posting and receiving at the same time. One possible solution: using another channel (which means one extra pair of split QP) mainly for flow control messages. When sending lots of 2-sided messages, extra number of QPs can cause overhead when we start many connections. This is the current implementation. We do not use 2-sided very often so this is fine.
(2) How to maintain the correct order of data being transferred? To make it simple, this question is equivalent to "How can the remote side know he's going to receive some split chunks, and how to make sure the user can only get the work completion when the last piece of data finishes transferring?" I couldn't think of a clean/elegant way to solve this issue.
Whether people actually use SEND/RECV to transfer a large amount of data (instead of using WRITE/WRITE_IMM) is another question to consider.

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

No branches or pull requests

1 participant