core: Count "frees per second" (fps) and do dynamic idling #433
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"Frees per second" (fps), literally the number of calls to
packet.free() per second, is introduced as a new basic metric for
measuring work done by a Snabb Switch process.
engine.Hz = false now uses a dynamic mechanism to decide how long to
sleep for depending on how busy/idle the process is, as observed from
fps. This is now the default setting and should be suitable for normal
usage.
Load on the process can be printed by calling
engine.report_load(). The load report looks like this:
load: time: 1.00s fps: 2,025,221 fpb: 304 bpp: 1280 sleep: 0 us
and the metrics mean:
time - period of time that the metrics were collected over
fps - frees per second
fpb - frees per breath
bpp - bytes per packet (average packet size)
The apps for an NFV port are now named starting with the port-id:
<port-id>..<app>
So that the link report will group together all of the lines for apps
that serve the same NFV port (due to simple lexical sorting).
Example:
link report:
4,858,198 sent on A_NIC.tx -> A_Virtio.rx (loss rate: 0%)
21,894,984 sent on A_Virtio.tx -> A_NIC.rx (loss rate: 0%)
21,894,260 sent on B_NIC.tx -> B_Virtio.rx (loss rate: 0%)
4,858,336 sent on B_Virtio.tx -> B_NIC.rx (loss rate: 0%)
These options and defaults are added:
-k SECONDS, --link-report-interval SECONDS
Print an link status report every SECONDS.
Default: 60s
-l SECONDS, --load-report-interval SECONDS
Print a processing load report every SECONDS.
Default: 1s
The output now looks like this:
load: time: 1.00s fps: 2,009,856 fpb: 313 bpp: 1247 sleep: 0 us
load: time: 1.00s fps: 2,015,442 fpb: 313 bpp: 1246 sleep: 0 us
load: time: 1.00s fps: 2,016,491 fpb: 314 bpp: 1242 sleep: 0 us
load: time: 1.00s fps: 2,012,131 fpb: 314 bpp: 1238 sleep: 0 us
load: time: 1.00s fps: 2,025,661 fpb: 321 bpp: 1216 sleep: 0 us
link report:
2,398,975 sent on A_NIC.tx -> A_Virtio.rx (loss rate: 0%)
11,793,998 sent on A_Virtio.tx -> A_NIC.rx (loss rate: 0%)
11,793,956 sent on B_NIC.tx -> B_Virtio.rx (loss rate: 0%)
2,398,990 sent on B_Virtio.tx -> B_NIC.rx (loss rate: 0%)
|
Added some follow-on changes for improving the messages printed to stdout. |
fpGbps estimates the physical 10GbE capacity required to carry the
packets that are being freed per second. This is counted from the size
in bytes of the packets being freed and accounting for 10GbE
overhead (minimum packet size, CRC, inter-packet gap).
The report format is now:
load: time: 1.00s fps: 2,114,697 fpGbps: 22.570 fpb: 293 bpp: 1325 sleep: 0 us
This is mostly useful for estimating link utilization. If you are
testing with two 10GbE links and your fpGbps is 20 then you are at the
theoretical maximum.
Practically speaking fpGbps is for estimating how close the process is
performing to "line rate" for its workload i.e. the maximum traffic
that can be carried over a physical link. (So you don't have to
memorize that if you are testing with 256-byte packets your line rate
is approx 4.45 Mpps, etc.)
Note: Measuring this when packets are freed my not be ideal because
encapsulations added and removed may be miscounted. In this case the
fpGbps metric would be superceded by a more practical alternative in
the future.
|
Couldn't resist: I added Example from an iperf run between two VMs connected via a local NIC. The VMs are showing 10.7 Gbps goodput in this example and one Snabb Switch process is serving both VMs: Here fpGbps of 22.5 makes sense for a 10GbE interface that is being driven in both directions at more than 100% of line rate (possible here because the 82599 NIC can forward between local VMs at more than 10Gbps). |
|
I start to wonder whether |
lukego
added a commit
that referenced
this pull request
Mar 30, 2015
core: Count "frees per second" (fps) and do dynamic idling
|
Merged because this feels like a big step in the right direction. |
|
Corner case: loadgen doesn't trigger dynamic idling because it doesn't perform any |
dpino
added a commit
to dpino/snabb
that referenced
this pull request
Sep 12, 2016
sanitize xml tags and include links pci and engine stats
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
"Frees per second" (fps), literally the number of calls to
packet.free() per second, is introduced as a new basic metric for
measuring work done by a Snabb Switch process.
engine.Hz = false now uses a dynamic mechanism to decide how long to
sleep for depending on how busy/idle the process is, as observed from
fps. This is now the default setting and should be suitable for normal
usage.
Load on the process can be printed by calling
engine.report_load(). The load report looks like this:
and the metrics mean: