-
Notifications
You must be signed in to change notification settings - Fork 78
GCC refactoring #306
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
base: master
Are you sure you want to change the base?
GCC refactoring #306
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #306 +/- ##
==========================================
- Coverage 71.69% 70.39% -1.31%
==========================================
Files 79 92 +13
Lines 4742 5164 +422
==========================================
+ Hits 3400 3635 +235
- Misses 1203 1389 +186
- Partials 139 140 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
7d3f0d9
to
0f9b5cc
Compare
0f9b5cc
to
101c527
Compare
101c527
to
7db4a7e
Compare
This PR is basically a rewrite of the bandwidth estimator without using any interceptor-specific concepts. Since it does not add an interceptor and can be used without interceptors, what do you think of moving the package into a separate repository which can then also hold alternative bandwidth estimator implementations? @Sean-Der @aalekseevx @JoeTurki |
@mengelbart, I like this idea. I think it would be convenient to keep the BWE implementation and tests in the same place. Maybe we can use the existing pion/bwe-test repository for this and rename it to pion/bwe? |
Hello, I agree with @aalekseevx, let's see what Sean see. |
pion/bwe sounds good. Unfortunately, I never got to really finish the test suite there, but it might be a good opportunity to finally straighten that out. |
I created pion/bwe-test#61 |
Description
This PR refactors the GCC implementation using the new API introduced in #300. Currently, users are responsible for creating a
SendSideController
, reading CCFB reports from the attributes, and passing them to theSendSideController
. This does not include pacing, which needs to be handled separately. Since the new controller does not need to read or pace outgoing packets, we no longer need the cumbersome callback API to get a pointer to the bandwidth estimator.This refactoring also cleans up the architecture of the bandwidth estimator. It no longer uses the weird pipelining structure and no longer uses any concurrency. This should also fix/close some of the open issues and PRs like #271, #299, #260, #221, #296.
This should not be merged before #300 is merged. A follow-up PR to this one will clean up the old
pkg/gcc
directory to use this version.