Skip to content
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' Option to SecNetPerf Server #1524

Open
nibanks opened this issue Apr 27, 2021 · 0 comments
Open

Add 'delay' Option to SecNetPerf Server #1524

nibanks opened this issue Apr 27, 2021 · 0 comments
Labels
Area: Performance feature request A request for new functionality good first issue Good for newcomers help wanted Extra attention is needed
Milestone

Comments

@nibanks
Copy link
Member

nibanks commented Apr 27, 2021

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:

  1. A new parameter (delay) that defaults to zero but can be overwritten at command line.
  2. If delay is non-zero, the perf server creates per-processor worker threads.
  3. On receipt of a stream (just ones that request app data?), if delay is 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 calling CxPlatTimeUs64()) for the delay time.
    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.

@nibanks nibanks added good first issue Good for newcomers feature request A request for new functionality Area: Performance labels Apr 27, 2021
@nibanks nibanks added this to the Future milestone Apr 27, 2021
@nibanks nibanks added the help wanted Extra attention is needed label May 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Performance feature request A request for new functionality good first issue Good for newcomers help wanted Extra attention is needed
Projects
Status: Should be written
Development

No branches or pull requests

1 participant