aboutgitcodebugslistschat
path: root/test/lib/perf_report
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2022-02-20 03:52:44 +0100
committerStefano Brivio <sbrivio@redhat.com>2022-02-21 13:41:13 +0100
commit6c931118643c8fa35935ddbd920cb669dec10021 (patch)
treec06030d619a7532bea73237713cf03868c039785 /test/lib/perf_report
parent9afd87b7334d8ea9cd7ca35b9f838a21ef093eaa (diff)
downloadpasst-6c931118643c8fa35935ddbd920cb669dec10021.tar
passt-6c931118643c8fa35935ddbd920cb669dec10021.tar.gz
passt-6c931118643c8fa35935ddbd920cb669dec10021.tar.bz2
passt-6c931118643c8fa35935ddbd920cb669dec10021.tar.lz
passt-6c931118643c8fa35935ddbd920cb669dec10021.tar.xz
passt-6c931118643c8fa35935ddbd920cb669dec10021.tar.zst
passt-6c931118643c8fa35935ddbd920cb669dec10021.zip
tcp, udp: Receive batching doesn't pay off when writing single frames to tap
In pasta mode, when we get data from sockets and write it as single frames to the tap device, we batch receive operations considerably, and then (conceptually) split the data in many smaller writes. It looked like an obvious choice, but performance is actually better if we receive data in many small frame-sized recvmsg()/recvmmsg(). The syscall overhead with the previous behaviour, observed by perf, comes predominantly from write operations, but receiving data in shorter chunks probably improves cache locality by a considerable amount. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'test/lib/perf_report')
0 files changed, 0 insertions, 0 deletions