-
Notifications
You must be signed in to change notification settings - Fork 462
UCP: wireup slow connect-to-iface lanes on demand #10640
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
Draft
evgeny-leksikov
wants to merge
26
commits into
openucx:master
Choose a base branch
from
evgeny-leksikov:ucp_wireup_ondemand_connect_to_iface2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
UCP: wireup slow connect-to-iface lanes on demand #10640
evgeny-leksikov
wants to merge
26
commits into
openucx:master
from
evgeny-leksikov:ucp_wireup_ondemand_connect_to_iface2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…oved lane retrieval
…ion and improved result reporting
…flags for lane-only checks and improving equality logic
…emand before cleanup
926bcb5
to
a210a31
Compare
…nd_connect_to_iface2
…o avoid comp.count overwrite
…nd_connect_to_iface2
- Added a new parameter for comparison flags to the ucp_ep_config_is_equal function. - Introduced flags for comparing lanes layout and performing a strong comparison.
…tor lane access functions - Refactored lane access functions to separate raw lane retrieval from the common access method. - Added new wireup message types: ADDR_REQUEST and ADDR_REPLY. - Refacored KA reply EP to be reused for ADDR_REPLY.
@evgeny-leksikov in very high level, makes sense. let's split |
…ndemand_connect_to_iface2
…ondemand_connect_to_iface2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Establish slow & connect-to-iface lanes on demand
Why?
with growing scale of systems p2p connection may have multiple alternative connection paths, not all of them can be utilized (depends on real usage of protocols), so we can safe resources
How?
ucp_ep_lane(lane_idx)
)