d/numam-dpdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

doc: fix default burst size in testpmd

Browse Source 
Default burst size in testpmd has been changed from 16 to 32
for some time now. But the documentation had not been updated.

Fixes: 836853d3d4 ("app/testpmd: increase default burst size to 32")
Cc: stable@dpdk.org

Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
This commit is contained in:
Ajit Khaparde 2021-05-28 10:45:29 -07:00 committed by Thomas Monjalon
parent f56a6ca4ed
commit 478614ee1f
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/guides/prog_guide/writing_efficient_code.rst
View File

@ -143,20 +143,21 @@ In order to achieve higher throughput,
the DPDK attempts to aggregate the cost of processing each packet individually by processing packets in bursts.
Using the testpmd application as an example,
the burst size can be set on the command line to a value of 16 (also the default value).
This allows the application to request 16 packets at a time from the PMD.
the burst size can be set on the command line to a value of 32 (also the default value).
This allows the application to request 32 packets at a time from the PMD.
The testpmd application then immediately attempts to transmit all the packets that were received,
in this case, all 16 packets.
in this case, all 32 packets.
The packets are not transmitted until the tail pointer is updated on the corresponding TX queue of the network port.
This behavior is desirable when tuning for high throughput because
the cost of tail pointer updates to both the RX and TX queues can be spread across 16 packets,
the cost of tail pointer updates to both the RX and TX queues can be spread
across 32 packets,
effectively hiding the relatively slow MMIO cost of writing to the PCIe* device.
However, this is not very desirable when tuning for low latency because
the first packet that was received must also wait for another 15 packets to be received.
It cannot be transmitted until the other 15 packets have also been processed because
the first packet that was received must also wait for another 31 packets to be received.
It cannot be transmitted until the other 31 packets have also been processed because
the NIC will not know to transmit the packets until the TX tail pointer has been updated,
which is not done until all 16 packets have been processed for transmission.
which is not done until all 32 packets have been processed for transmission.
To consistently achieve low latency, even under heavy system load,
the application developer should avoid processing packets in bunches.