-
Notifications
You must be signed in to change notification settings - Fork 526
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
Add Priority Connection Queue to Worker #4386
base: main
Are you sure you want to change the base?
Conversation
d4f36b0
to
c9950eb
Compare
Random stall issue |
QuicWorkerQueueConnection has the cause of stall. but then priority mechanism randomly fail |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4386 +/- ##
==========================================
- Coverage 85.02% 85.00% -0.03%
==========================================
Files 56 56
Lines 15457 15485 +28
==========================================
+ Hits 13143 13163 +20
- Misses 2314 2322 +8 ☔ View full report in Codecov by Sentry. |
ExpectedStartOrder[0] = &Stream1; | ||
ExpectedStartOrder[1] = &Stream4; | ||
ExpectedStartOrder[2] = &Stream2; | ||
ExpectedStartOrder[3] = &Stream5; | ||
ExpectedStartOrder[4] = &Stream3; | ||
ExpectedSendOrder[0] = &Stream1; | ||
ExpectedSendOrder[1] = &Stream4; | ||
ExpectedSendOrder[2] = &Stream2; | ||
ExpectedSendOrder[3] = &Stream5; | ||
ExpectedSendOrder[4] = &Stream3; | ||
|
||
TEST_TRUE(memcmp(Context.StartOrder, ExpectedStartOrder, sizeof(ExpectedStartOrder)) == 0); | ||
TEST_TRUE(memcmp(Context.SendOrder, ExpectedSendOrder, sizeof(ExpectedSendOrder)) == 0); |
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.
Sometimes [3] and [4] (non prioritized operations) are flipped. timing issue
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.
But how operations in FIFO queue with 1:1 producer : consumer swap.....
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.
Found the cause.
There is a case when [3] is in worker queue before explicitly enqueue operation by API.
Conventional enqueue doesn't re-enqueue the connection. Prioritized enqueue does.
This PR itself is ready to go. spinquic has stall issue. Investigation in progress |
RegConfig.ExecutionProfile = QUIC_EXECUTION_PROFILE_TYPE_SCAVENGER doesn't resolve the stall. |
@nibanks |
macOS only uses 1 CPU / worker thread, so all the scheduling/timings will be very different |
Description
This build on #4279 and now adds the prioritization logic at the worker queue level. High priority operations queued on a connection now result in a connection being high priority on its worker.
Testing
CI/CD
Documentation
N/A