-
Notifications
You must be signed in to change notification settings - Fork 552
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 "delay" and "delayType" options to secnetperf tool #4807
base: main
Are you sure you want to change the base?
Conversation
- Default/fixed delay introduces specific microseconds of inline busy-wait delay when the stream is established - Variable delay introduces an exponetially distributed random busy-wait delay. This is capped at 1millisecond inline sleep. - Documentation/help text updated
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4807 +/- ##
==========================================
- Coverage 87.43% 86.91% -0.53%
==========================================
Files 56 56
Lines 17634 17634
==========================================
- Hits 15419 15326 -93
- Misses 2215 2308 +93 ☔ View full report in Codecov by Sentry. |
…and sending responses from the server. - Based on the perflib TCP worker threadpool code - 1 worker thread per processor - Existing code (QUIC/TCP) queues background work on the current processor only when a server response is due. - The existing Quic/TCP connection/stream is assumed to be available till the background operation completes - DelayWork thread adds appropriate amount of delay and then sends the response back on the appropriate stream *Minor code reorganization in PerfServer.h *Addressed review comments from prior iteration
InterlockedFetchAndSetBoolean(&ExecutionContext.Ready); | ||
ExecutionContext.NextTimeUs = UINT64_MAX; | ||
|
||
uint16_t ThreadFlags = CXPLAT_THREAD_FLAG_SET_IDEAL_PROC; |
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.
Not really necessary to make a separate variable just for this.
|
||
uint16_t ThreadFlags = CXPLAT_THREAD_FLAG_SET_IDEAL_PROC; | ||
// | ||
// Not using the high priority flag for delay threads |
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.
Let's just remove this comment. Most things don't run at high priority, so saying this isn't using that is unnecessary IMO.
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.
This is in contrast with other threadpools we use in this binary and we have to highlight it somehow..
if (nullptr == Work) { | ||
return false; | ||
} |
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.
Since this is test/tool code, we generally assume allocation success. Let's remove this check, which simplifies the whole function (it can't fail then) as well as the callers.
" -delay:<####>[unit] Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. (def:0)\n" | ||
" -delayType:<fixed|variable> Optional delay type can be specified in conjunction with the 'delay' argument.\n" |
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.
" -delay:<####>[unit] Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. (def:0)\n" | |
" -delayType:<fixed|variable> Optional delay type can be specified in conjunction with the 'delay' argument.\n" | |
" -delay:<####>[unit] Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. (def:0)\n" | |
" -delayType:<type> Optional delay type can be specified in conjunction with the 'delay' argument.\n" |
We generally use this convention for parameters
@@ -29,6 +29,8 @@ ecn | `-ecn:<0,1>` | Enables sender-side ECN support. | |||
exec | `-exec:<lowlat,maxtput,scavenger,realtime>` | The execution profile used for the application. | |||
pollidle | `-pollidle:<time_us>` | The time, in microseconds, to poll while idle before sleeping (falling back to interrupt-driven IO). | |||
stats | `-stats:<0,1>` | Prints out statistics at the end of each connection. | |||
delay | `[-delay:<value>[units]]` | Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. (default: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.
delay | `[-delay:<value>[units]]` | Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. (default:0) | |
delay | `[-delay:<value>[units]]` | Delay, with an optional unit (def unit is us), to be introduced before the server responds to a request. |
CXPLAT_THREAD_CALLBACK(DelayWorker::WorkerThread, Context) | ||
{ | ||
DelayWorker* This = (DelayWorker*)Context; | ||
CXPLAT_EXECUTION_STATE DummyState = { |
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.
You're never using CXPLAT_EXECUTION_STATE
anywhere. Go ahead and remove all references.
This->m_Server->SimulateDelay(); | ||
This->m_Server->SendResponse(WorkItem->Context, WorkItem->Handle, WorkItem->IsTcp); | ||
delete WorkItem; | ||
InterlockedFetchAndSetBoolean(&This->ExecutionContext.Ready); // We just did work, let's keep this thread hot. |
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.
The usage of ExecutionContext and Ready
is overkill here. I'm pretty sure we can just remove it. In general, you just need the queue and the wake event I think.
This not quite the same as the feature request described in issue #1524, but it achieves some of the goals. The stream processing on the server side is already multithreaded and the use of exponential probability distribution to determine the delay for the current stream simulates variable processing time for a request on the server side.
We can introduce background thread processing as suggested in the issue description to simulate further processing delays on the server side to enable a richer simluation.
Description
Add the ability to introduce server-side delays into data streams in the secnetperf tool.
Testing
This change updates the test tool. Existing tests are all passing with this change.
Documentation
Documentation has been updated.