diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2022-02-20 03:52:44 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2022-02-21 13:41:13 +0100 |
commit | 6c931118643c8fa35935ddbd920cb669dec10021 (patch) | |
tree | c06030d619a7532bea73237713cf03868c039785 /Makefile | |
parent | 9afd87b7334d8ea9cd7ca35b9f838a21ef093eaa (diff) | |
download | passt-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 'Makefile')
0 files changed, 0 insertions, 0 deletions