-
Notifications
You must be signed in to change notification settings - Fork 26.3k
[RPC] Infer backend type if only options are given #45065
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
To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/) [ghstack-poisoned]
To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/) ghstack-source-id: 112484729 Pull Request resolved: #45065
| f"RPC was initialized with no explicit backend but with options " | ||
| f"corresponding to {backend}, hence that backend will be used " | ||
| f"instead of the default {BackendType.TENSORPIPE}. To silence this " | ||
| f"warning pass `backend={backend}` explicitly." |
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.
Should we also add a deprecation warning about ProcessGroup since our long-term plan is to remove it?
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.
Yes, it would be good to add a deprecation warning too.
💊 CI failures summary and remediationsAs of commit f3c1fcf (more details on the Dr. CI page):
Extra GitHub checks: 1 failed
codecov.io: 1 failed
This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions on the GitHub issue tracker or post in the (internal) Dr. CI Users group. This comment has been revised 11 times. |
Codecov Report
@@ Coverage Diff @@
## gh/lw/76/base #45065 +/- ##
=================================================
- Coverage 67.83% 67.78% -0.06%
=================================================
Files 384 384
Lines 50047 50106 +59
=================================================
+ Hits 33950 33962 +12
- Misses 16097 16144 +47
Continue to review full report at Codecov.
|
| f"RPC was initialized with no explicit backend but with options " | ||
| f"corresponding to {backend}, hence that backend will be used " | ||
| f"instead of the default {BackendType.TENSORPIPE}. To silence this " | ||
| f"warning pass `backend={backend}` explicitly." |
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.
Yes, it would be good to add a deprecation warning too.
| if backend is None: | ||
| backend = BackendType.TENSORPIPE | ||
|
|
||
| if rpc_backend_options is None: |
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.
What happens if backend is specified as TensorPipe but backend options are ProcessGroupOptions? Do we raise an appropriate error? If so, can we have a unit test that verifies this?
| backend = candidate_backend | ||
| break |
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.
Are these codecov warnings false positives? It does seem like your test should cover this line?
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.
That's unclear. I'm assuming that the coverage is collected from this job: https://app.circleci.com/pipelines/github/pytorch/pytorch/217281/workflows/3cfc25f2-225c-4be1-9ad5-a7942dc829e7/jobs/7659664 (since it's the only one with coverage in the name). And I checked the logs and the tests are run.
One option is that the odd on-the-fly class construction trick we're doing to assemble the RPC test suites makes it hard for the coverage tool to map the test back to its original lines.
Or I misunderstood how this works.
| backend = candidate_backend | ||
| break | ||
| else: | ||
| raise TypeError( |
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.
Can we add a test covering this?
To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/) [ghstack-poisoned]
Pull Request resolved: #45065 To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. ghstack-source-id: 112582130 Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/)
To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/) [ghstack-poisoned]
Pull Request resolved: #45065 To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change. ghstack-source-id: 112586258 Differential Revision: [D23814289](https://our.internmc.facebook.com/intern/diff/D23814289/)
|
This pull request has been merged in 76dc50e. |
Stack from ghstack:
To preserve backwards compatibility with applications that were passing in some ProcessGroupRpcBackendOptions but were not explicitly setting backend=BackendType.PROCESS_GROUP, we're here now inferring the backend type from the options if only the latter ones are passed. If neither are passed, we'll default to TensorPipe, as before this change.
Differential Revision: D23814289