aboutgitcodebugslistschat
path: root/README.md
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 /README.md
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 'README.md')
0 files changed, 0 insertions, 0 deletions