Add 'delay' Option to SecNetPerf Server
Describe the feature you'd like supported
Currently, secnetperf server side immediately responds to incoming stream data requests from the peer (inline). This does a great job of measuring the best possible case scenario, and gives us an idea of the upper bounds of maximum achievable performance. The problem though, is that it doesn't practically mimic a real application's behavior. Perhaps in some cases an app might have cached data it can immediately return inline, but most of the time I expect the app to queue work to its own thread and only when that's complete, send the response back to the client.
In order to support mimicking a more realistic app behavior, we should add a new command line option delay that allows the user to specify a time (in microseconds) that the server should execute "work" on it's own thread before queuing the necessary response.
Proposed solution
Practically, this will entail the following changes:
- A new parameter (
delay) that defaults to zero but can be overwritten at command line. - If
delayis non-zero, the perf server creates per-processor worker threads. - On receipt of a stream (just ones that request app data?), if
delayis non-zero queues a "work item" to the worker threads. a. When the work item executes it runs "does work" (sit in a loop running callingCxPlatTimeUs64()) for thedelaytime. b. Then it queued the data on the stream
Synchronization of the work and a stream/connection possibly getting shutdown might be a bit tricky.