- dev - passt

[RFC net-next] tcp: add support for read with offset when using MSG_PEEK
by jmaloy＠redhat.com 22 Jan '24

22 Jan '24

From: Jon Maloy <jmaloy(a)redhat.com> When reading received messages from a socket with MSG_PEEK, we may want to read the contents with an offset, like we can do with pread/preadv() when reading files. Currently, it is not possible to do that. In this commit, we allow the user to set iovec.iov_base in the first vector entry to NULL. This tells the socket to skip the first entry, hence letting the iov_len field of that entry indicate the offset value. This way, there is no need to add any new arguments or flags. In the iperf3 log examples shown below, we can observe a throughput improvement of ~15 % in the direction host->namespace when using the protocol splicer 'pasta' (https://passt.top). This is a consistent result. pasta(1) and passt(1) implement user-mode networking for network namespaces (containers) and virtual machines by means of a translation layer between Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo). Received, pending TCP data to the container/guest is kept in kernel buffers until acknowledged, so the tool routinely needs to fetch new data from socket, skipping data that was already sent. At the moment this is implemented using a dummy buffer passed to recvmsg(). With this change, we don't need a dummy buffer and the related buffer copy (copy_to_user()) anymore. passt and pasta are supported in KubeVirt and libvirt/qemu. jmaloy@freyr:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset not supported by kernel. jmaloy@freyr:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 44822 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 44832 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.02 GBytes 8.78 Gbits/sec [ 5] 1.00-2.00 sec 1.06 GBytes 9.08 Gbits/sec [ 5] 2.00-3.00 sec 1.07 GBytes 9.15 Gbits/sec [ 5] 3.00-4.00 sec 1.10 GBytes 9.46 Gbits/sec [ 5] 4.00-5.00 sec 1.03 GBytes 8.85 Gbits/sec [ 5] 5.00-6.00 sec 1.10 GBytes 9.44 Gbits/sec [ 5] 6.00-7.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 7.00-8.00 sec 1.07 GBytes 9.20 Gbits/sec [ 5] 8.00-9.00 sec 667 MBytes 5.59 Gbits/sec [ 5] 9.00-10.00 sec 1.03 GBytes 8.83 Gbits/sec [ 5] 10.00-10.04 sec 30.1 MBytes 6.36 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 10.3 GBytes 8.78 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated jmaloy@freyr:~/passt# logout [ perf record: Woken up 23 times to write data ] [ perf record: Captured and wrote 5.696 MB perf.data (35580 samples) ] jmaloy@freyr:~/passt$ jmaloy@freyr:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset supported by kernel. jmaloy@freyr:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 40854 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 40862 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 1.00-2.00 sec 1.19 GBytes 10.2 Gbits/sec [ 5] 2.00-3.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 3.00-4.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 4.00-5.00 sec 1.20 GBytes 10.3 Gbits/sec [ 5] 5.00-6.00 sec 1.14 GBytes 9.80 Gbits/sec [ 5] 6.00-7.00 sec 1.17 GBytes 10.0 Gbits/sec [ 5] 7.00-8.00 sec 1.12 GBytes 9.61 Gbits/sec [ 5] 8.00-9.00 sec 1.13 GBytes 9.74 Gbits/sec [ 5] 9.00-10.00 sec 1.26 GBytes 10.8 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 11.8 GBytes 10.1 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated logout [ perf record: Woken up 20 times to write data ] [ perf record: Captured and wrote 5.040 MB perf.data (33411 samples) ] jmaloy@freyr:~/passt$ The perf record confirms this result. Below, we can observe that the CPU spends significantly less time in the function ____sys_recvmsg() when we have offset support. Without offset support: ---------------------- jmaloy@freyr:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 46.32% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg With offset support: ---------------------- jmaloy@freyr:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 27.24% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg Reviewed-by: Stefano Brivio <sbrivio(a)redhat.com> Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- net/ipv4/tcp.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 1baa484d2190..82e1da3f0f98 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2351,6 +2351,20 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, if (flags & MSG_PEEK) { peek_seq = tp->copied_seq; seq = &peek_seq; + if (!msg->msg_iter.__iov[0].iov_base) { + size_t peek_offset; + + if (msg->msg_iter.nr_segs < 2) { + err = -EINVAL; + goto out; + } + peek_offset = msg->msg_iter.__iov[0].iov_len; + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + msg->msg_iter.nr_segs -= 1; + msg->msg_iter.count -= peek_offset; + len -= peek_offset; + *seq += peek_offset; + } } target = sock_rcvlowat(sk, flags & MSG_WAITALL, len); -- 2.42.0

4 4

[RFC net-next v2] tcp: add support for read with offset when using MSG_PEEK
by jmaloy＠redhat.com 20 Jan '24

20 Jan '24

From: Jon Maloy <jmaloy(a)redhat.com> When reading received messages from a socket with MSG_PEEK, we may want to read the contents with an offset, like we can do with pread/preadv() when reading files. Currently, it is not possible to do that. In this commit, we allow the user to set iovec.iov_base in the first vector entry to NULL. This tells the socket to skip the first entry, hence letting the iov_len field of that entry indicate the offset value. This way, there is no need to add any new arguments or flags. In the iperf3 log examples shown below, we can observe a throughput improvement of ~15 % in the direction host->namespace when using the protocol splicer 'pasta' (https://passt.top). This is a consistent result. pasta(1) and passt(1) implement user-mode networking for network namespaces (containers) and virtual machines by means of a translation layer between Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo). Received, pending TCP data to the container/guest is kept in kernel buffers until acknowledged, so the tool routinely needs to fetch new data from socket, skipping data that was already sent. At the moment this is implemented using a dummy buffer passed to recvmsg(). With this change, we don't need a dummy buffer and the related buffer copy (copy_to_user()) anymore. passt and pasta are supported in KubeVirt and libvirt/qemu. jmaloy@freyr:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset not supported by kernel. jmaloy@freyr:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 44822 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 44832 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.02 GBytes 8.78 Gbits/sec [ 5] 1.00-2.00 sec 1.06 GBytes 9.08 Gbits/sec [ 5] 2.00-3.00 sec 1.07 GBytes 9.15 Gbits/sec [ 5] 3.00-4.00 sec 1.10 GBytes 9.46 Gbits/sec [ 5] 4.00-5.00 sec 1.03 GBytes 8.85 Gbits/sec [ 5] 5.00-6.00 sec 1.10 GBytes 9.44 Gbits/sec [ 5] 6.00-7.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 7.00-8.00 sec 1.07 GBytes 9.20 Gbits/sec [ 5] 8.00-9.00 sec 667 MBytes 5.59 Gbits/sec [ 5] 9.00-10.00 sec 1.03 GBytes 8.83 Gbits/sec [ 5] 10.00-10.04 sec 30.1 MBytes 6.36 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 10.3 GBytes 8.78 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated jmaloy@freyr:~/passt# logout [ perf record: Woken up 23 times to write data ] [ perf record: Captured and wrote 5.696 MB perf.data (35580 samples) ] jmaloy@freyr:~/passt$ jmaloy@freyr:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset supported by kernel. jmaloy@freyr:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 40854 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 40862 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 1.00-2.00 sec 1.19 GBytes 10.2 Gbits/sec [ 5] 2.00-3.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 3.00-4.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 4.00-5.00 sec 1.20 GBytes 10.3 Gbits/sec [ 5] 5.00-6.00 sec 1.14 GBytes 9.80 Gbits/sec [ 5] 6.00-7.00 sec 1.17 GBytes 10.0 Gbits/sec [ 5] 7.00-8.00 sec 1.12 GBytes 9.61 Gbits/sec [ 5] 8.00-9.00 sec 1.13 GBytes 9.74 Gbits/sec [ 5] 9.00-10.00 sec 1.26 GBytes 10.8 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 11.8 GBytes 10.1 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated logout [ perf record: Woken up 20 times to write data ] [ perf record: Captured and wrote 5.040 MB perf.data (33411 samples) ] jmaloy@freyr:~/passt$ The perf record confirms this result. Below, we can observe that the CPU spends significantly less time in the function ____sys_recvmsg() when we have offset support. Without offset support: ---------------------- jmaloy@freyr:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 46.32% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg With offset support: ---------------------- jmaloy@freyr:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 27.24% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v2: Put test of msg->msg_iter.nr_segs before test on msg->msg_iter.__iov, since the latter may be uninitialized when other receive functions are used. Reported by Martin Zaharinov. --- net/ipv4/tcp.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index fce5668a6a3d..e8fdf3617377 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2351,6 +2351,16 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, if (flags & MSG_PEEK) { peek_seq = tp->copied_seq; seq = &peek_seq; + if (msg->msg_iter.nr_segs > 1 && !msg->msg_iter.__iov[0].iov_base) { + size_t peek_offset; + + peek_offset = msg->msg_iter.__iov[0].iov_len; + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + msg->msg_iter.nr_segs -= 1; + msg->msg_iter.count -= peek_offset; + len -= peek_offset; + *seq += peek_offset; + } } target = sock_rcvlowat(sk, flags & MSG_WAITALL, len); -- 2.42.0

1 0

[PATCH v2] tcp.c: leverage MSG_PEEK with offset kernel capability when available
by Jon Maloy 20 Jan '24

20 Jan '24

The kernel may support recvmsg(MSG_PEEK), starting from a given offset. This makes it possible to avoid repeated reading of already read initial bytes of a received message, hence saving us read cycles when forwarding TCP messages in the host->name space direction. When this feature is supported, iov_sock[0].iov_base can be set to NULL. The kernel code will interpret this as an instruction to skip reading of the first iov_sock[0].iov_len bytes of the message. Since iov_sock[0].iov_base is set to point to tcp_buf_discard, we do this by making this into a pointer, setting it to NULL if we find that the feature is supported by the kernel, an letting it point to a static buffer if not. There is no macro or function indicating kernel support for this feature. We therefore have to probe for it by creating a temporary tcp connection and read from it as if the feature is present. If that fails, we fall back to the original design. The traffic connection cannot be used for this purpose, because it will be broken if the probe reading fails. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v2: Changes as suggested by Stefano Brivio: - Moved probe process/function into a separate, temporary name space, to avoid occupying port numbers in the current name space. - Put discard buffer back to static memory. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- netlink.c | 2 +- netlink.h | 1 + tcp.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 3 files changed, 103 insertions(+), 3 deletions(-) diff --git a/netlink.c b/netlink.c index 379d46e..d5f10de 100644 --- a/netlink.c +++ b/netlink.c @@ -55,7 +55,7 @@ static int nl_seq = 1; * * Return: 0 */ -static int nl_sock_init_do(void *arg) +int nl_sock_init_do(void *arg) { struct sockaddr_nl addr = { .nl_family = AF_NETLINK, }; int *s = arg ? &nl_sock_ns : &nl_sock; diff --git a/netlink.h b/netlink.h index 3a1f0de..cadd3b7 100644 --- a/netlink.h +++ b/netlink.h @@ -24,5 +24,6 @@ int nl_addr_dup(int s_src, unsigned int ifi_src, int nl_link_get_mac(int s, unsigned int ifi, void *mac); int nl_link_set_mac(int s, unsigned int ifi, const void *mac); int nl_link_up(int s, unsigned int ifi, int mtu); +int nl_sock_init_do(void *arg); #endif /* NETLINK_H */ diff --git a/tcp.c b/tcp.c index f506cfd..4410460 100644 --- a/tcp.c +++ b/tcp.c @@ -283,6 +283,7 @@ #include <sys/timerfd.h> #include <sys/types.h> #include <sys/uio.h> +#include <sys/wait.h> #include <time.h> #include <linux/tcp.h> /* For struct tcp_info */ @@ -297,6 +298,7 @@ #include "log.h" #include "inany.h" #include "flow.h" +#include "netlink.h" #include "tcp_conn.h" #include "flow_table.h" @@ -402,6 +404,8 @@ struct tcp6_l2_head { /* For MSS6 macro: keep in sync with tcp6_l2_buf_t */ (conn->events & (SOCK_FIN_RCVD | TAP_FIN_RCVD))) #define CONN_HAS(conn, set) ((conn->events & (set)) == (set)) +static bool tcp_probe_msg_peek_offset_cap(); + static const char *tcp_event_str[] __attribute((__unused__)) = { "SOCK_ACCEPTED", "TAP_SYN_RCVD", "ESTABLISHED", "TAP_SYN_ACK_SENT", @@ -506,7 +510,8 @@ static struct tcp_buf_seq_update tcp6_l2_buf_seq_update[TCP_FRAMES_MEM]; static unsigned int tcp6_l2_buf_used; /* recvmsg()/sendmsg() data for tap */ -static char tcp_buf_discard [MAX_WINDOW]; +static char tcp_discard_buf[MAX_WINDOW]; +static char* tcp_buf_discard = tcp_discard_buf; static struct iovec iov_sock [TCP_FRAMES_MEM + 1]; static struct iovec tcp4_l2_iov [TCP_FRAMES_MEM]; @@ -573,6 +578,15 @@ static unsigned int tcp6_l2_flags_buf_used; #define CONN(idx) (&(FLOW(idx)->tcp)) + +/** msg_peek_offset_cap() - Does the kernel support recvmsg(MSG_PEEK) with offset? + */ +static inline bool msg_peek_offset_cap() +{ + return !tcp_buf_discard; +} + + /** conn_at_idx() - Find a connection by index, if present * @idx: Index of connection to lookup * @@ -2224,7 +2238,9 @@ static int tcp_data_from_sock(struct ctx *c, struct tcp_tap_conn *conn) return 0; } - sendlen = len - already_sent; + sendlen = len; + if (!msg_peek_offset_cap()) + sendlen -= already_sent; if (sendlen <= 0) { conn_flag(c, conn, STALLED); return 0; @@ -3107,6 +3123,9 @@ int tcp_init(struct ctx *c) NS_CALL(tcp_ns_socks_init, c); } + /* Ignore discard buffer if not needed */ + if (tcp_probe_msg_peek_offset_cap()) + tcp_buf_discard = NULL; return 0; } @@ -3213,3 +3232,83 @@ void tcp_timer(struct ctx *c, const struct timespec *ts) if (c->mode == MODE_PASTA) tcp_splice_refill(c); } + +static int tcp_probe_sockets(void *arg) +{ + char b; + struct iovec iov[2] = { { NULL, 1 }, { &b, 1 }, }; + struct msghdr msg = { NULL, 0, iov, 2, NULL, 0, 0}; + struct sockaddr a = { AF_INET, {0, }}; + int err = EXIT_FAILURE; + int s[2] = {0, }; + int s_recv = 0; + int *rc = arg; + ssize_t len; + + /* Make sure loopback interface is enabled */ + nl_sock_init_do(NULL); + nl_link_up(nl_sock, 1 /* lo */, 0); + + s[0] = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); + s[1] = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP); + if (s[0] < 0 || s[1] < 0) { + perror("Temporary probe socket creation failed\n"); + goto out; + } + if (0 > bind(s[0], &a, sizeof(a))) { + perror("Temporary probe socket bind() failed\n"); + goto out; + } + if (0 > getsockname(s[0], &a, &((socklen_t) { sizeof(a) }))) { + perror("Temporary probe socket getsockname() failed\n"); + goto out; + } + if (0 > listen(s[0], 0)) { + perror("Temporary probe socket listen() failed\n"); + goto out; + } + if (0 <= connect(s[1], &a, sizeof(a)) || errno != EINPROGRESS) { + perror("Temporary probe socket connect() failed\n"); + goto out; + } + s_recv = accept(s[0], NULL, NULL); + if (s_recv <= 0) { + perror("Temporary probe socket accept() failed\n"); + goto out; + } + if (0 >= send(s[1], (char *)("ab"), 2, 0) || errno != EINPROGRESS) { + perror("Temporary probe socket send() failed\n"); + goto out; + } + len = recvmsg(s_recv, &msg, MSG_PEEK); + if (len <= 0 && errno != EFAULT) { + perror("Temporary probe socket recvmsg() failed\n"); + goto out; + } + printf("MSG_PEEK with offset %ssupported\n", len == 1 ? "" : "not "); + *rc = len == 1; + err = EXIT_SUCCESS; +out: + close(s_recv); + close(s[1]); + close(s[0]); + return err; +} + +/** tcp_probe_msg_peek_offset_cap() - Probe kernel for MSG_PEEK with offset support + */ +static bool tcp_probe_msg_peek_offset_cap() +{ + char ns_fn_stack[NS_FN_STACK_SIZE]; + int child_pid, child_ret, rc = 0; + + child_pid = do_clone(tcp_probe_sockets, ns_fn_stack, sizeof(ns_fn_stack), + CLONE_NEWNET | CLONE_NEWUSER | CLONE_VM | CLONE_VFORK | CLONE_FILES | SIGCHLD, + (void *)&rc); + if (child_pid <= 0) { + perror("Failed to clone tcp probe process\n"); + exit(EXIT_FAILURE); + } + waitpid(child_pid, &child_ret, 0); + return rc; +} -- 2.39.2

3 5

[PATCH v3 00/15] RFC: Unified flow table
by David Gibson 19 Jan '24

19 Jan '24

This is a third draft of the first steps in implementing more general "connection" tracking, as described at: https://pad.passt.top/p/NewForwardingModel This series changes the TCP connection table and hash table into a more general flow table that can track other protocols as well. Each flow uniformly keeps track of all the relevant addresses and ports, which will allow for more robust control of NAT and port forwarding. ICMP is converted to use the new flow table. Caveats: * We significantly increase the size of a connection/flow entry - Can probably be mitigated, but I haven't investigated much yet * We perform a number of extra getsockname() calls to know some of the socket endpoints - Haven't yet measured how much performance impact that has - Can be mitigated in at least some cases, but again, haven't tried yet * UDP is not converted yet Changes since v2: * Cosmetic fixes based on review * Extra doc comments for enum flow_type * Rename flowside to flowaddrs which turns out to make more sense in light of future changes * Fix bug where the socket flowaddrs for tap initiated connections wasn't initialised to match the socket address we were using in the case of map-gw NAT * New flowaddrs_from_sock() helper used in most cases which is cleaner and should avoid bugs like the above * Using newer centralised workarounds for clang-tidy issue 58992 * Remove duplicate definition of FLOW_MAX as maximum flow type and maximum number of tracked flows * Rebased on newer versions of preliminary work (ICMP, flow based dispatch and allocation, bind/address cleanups) * Unified hash table as well as base flow table * Integrated ICMP Changes since v1: * Terminology changes - "Endpoint" address/port instead of "correspondent" address/port - "flowside" instead of "demiflow" * Actually move the connection table to a new flow table structure in new files * Significant rearrangement of earlier patchs on top of that new table, to reduce churn David Gibson (15): flow: Common data structures for tracking flow addresses tcp, flow: Maintain guest side flow information tcp, flow: Maintain host side flow information tcp_splice,flow: Maintain flow information for spliced connections flow, tcp, tcp_splice: Uniform debug helpers for new flows tcp, flow: Replace TCP specific hash function with general flow hash flow: Add helper to determine a flow's protocol flow, tcp: Generalise TCP hash table to general flow hash table tcp: Re-use flow hash for initial sequence number generation icmp: Store ping socket information in the flow table icmp: Populate guest side information for ping flows icmp: Populate and use host side flow information icmp: Use 'flowside' epoll references for ping sockets icmp: Merge EPOLL_TYPE_ICMP and EPOLL_TYPE_ICMPV6 icmp: Eliminate icmp_id_map Makefile | 6 +- flow.c | 260 ++++++++++++++++++++++++++++++++++++++++++ flow.h | 104 +++++++++++++++++ flow_table.h | 2 + icmp.c | 211 +++++++++++++++++++--------------- icmp.h | 15 +-- icmp_flow.h | 31 +++++ passt.c | 15 +-- passt.h | 9 +- tap.c | 11 -- tap.h | 1 - tcp.c | 313 +++++++++++++++------------------------------------ tcp_conn.h | 9 -- tcp_splice.c | 63 ++++++++--- tcp_splice.h | 3 +- util.c | 4 +- util.h | 18 +++ 17 files changed, 683 insertions(+), 392 deletions(-) create mode 100644 icmp_flow.h -- 2.43.0

2 32

[PATCH 0/3] Assorted fixes
by David Gibson 16 Jan '24

16 Jan '24

2 4

[PATCH] test: Fix passt.mbuto for cases where /usr/sbin doesn't exist
by David Gibson 15 Jan '24

15 Jan '24

f0ccca74 ("test: make passt.mbuto script more robust") is supposed to make mbuto more robust by standardizing on always putting things in /usr/sbin with /sbin a symlink to it. This matters because different distros have different conventions about how the two are used. However, the logic there requires that /usr/sbin at least exists to start with. This isn't always the case with Fedora derived mbuto images. Ironically the DIRS variable ensures that /sbin exists, although we then remove it, but doesn't require /usr/sbin to exist. Fix that up so that the new logic will work with Fedora. Fixes: f0ccca74 ("test: make passt.mbuto script more robust") Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- test/passt.mbuto | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/passt.mbuto b/test/passt.mbuto index 75d1260..6240d5c 100755 --- a/test/passt.mbuto +++ b/test/passt.mbuto @@ -21,7 +21,7 @@ LINKS="${LINKS:- ash,dash,bash /init ash,dash,bash /bin/sh}" -DIRS="${DIRS} /tmp /sbin /usr/share /var/log /var/lib /etc/ssh /run/sshd /root/.ssh" +DIRS="${DIRS} /tmp /usr/sbin /usr/share /var/log /var/lib /etc/ssh /run/sshd /root/.ssh" COPIES="${COPIES} small.bin,/root/small.bin medium.bin,/root/medium.bin big.bin,/root/big.bin" -- 2.43.0

1 0

[PATCH 0/8] Small cleanups related to addresses and binding
by David Gibson 13 Jan '24

13 Jan '24

Here's another batch of cleanups for minor warts I noticed while working on flow table things. David Gibson (8): tcp: Fix address type for tcp_sock_init_af() treewide: Use IN4ADDR_LOOPBACK_INIT more widely treewide: Add IN4ADDR_ANY_INIT macro util: Use htonl_constant() in more places util: Improve sockaddr initialisation in sock_l4() icmp: Avoid unnecessary handling of unspecified bind address treewide: Avoid in_addr_t util: Make sock_l4() treat empty string ifname like NULL icmp.c | 27 ++++++--------------------- tcp.c | 4 ++-- tcp_splice.c | 2 +- udp.c | 14 ++++++-------- util.c | 12 ++++-------- util.h | 7 +++++-- 6 files changed, 24 insertions(+), 42 deletions(-) -- 2.43.0

2 16

[RFC net-next] tcp: add support for read with offset when using MSG_PEEK
by jmaloy＠redhat.com 11 Jan '24

11 Jan '24

From: Jon Maloy <jmaloy(a)redhat.com> When reading received messages with MSG_PEEK, we sometines have to read the leading bytes of the stream several times, only to reach the bytes we really want. This is clearly non-optimal. What we would want is something similar to pread/preadv(), but working even for tcp sockets. At the same time, we don't want to add any new arguments to the recv/recvmsg() calls. In this commit, we allow the user to set iovec.iov_base in the first vector entry to NULL. This tells the socket to skip the first entry, hence letting the iov_len field of that entry indicate the offset value. This way, there is no need to add any new arguments or flags. In the iperf3 logs examples shown below, we can observe a throughput improvement of ~20 % in the direction host->namespace when using the protocol splicer 'passt'. This is a consistent result. $ ./passt/passt/pasta --config-net -f MSG_PEEK with offset not supported. [root@fedora37 ~]# perf record iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 60344 [ 6] local 192.168.122.163 port 5201 connected to 192.168.122.1 port 60360 [ ID] Interval Transfer Bitrate {...] [ 6] 13.00-14.00 sec 2.54 GBytes 21.8 Gbits/sec [ 6] 14.00-15.00 sec 2.52 GBytes 21.7 Gbits/sec [ 6] 15.00-16.00 sec 2.50 GBytes 21.5 Gbits/sec [ 6] 16.00-17.00 sec 2.49 GBytes 21.4 Gbits/sec [ 6] 17.00-18.00 sec 2.51 GBytes 21.6 Gbits/sec [ 6] 18.00-19.00 sec 2.48 GBytes 21.3 Gbits/sec [ 6] 19.00-20.00 sec 2.49 GBytes 21.4 Gbits/sec [ 6] 20.00-20.04 sec 87.4 MBytes 19.2 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-20.04 sec 48.9 GBytes 21.0 Gbits/sec receiver ----------------------------------------------------------- [jmaloy@fedora37 ~]$ ./passt/passt/pasta --config-net -f MSG_PEEK with offset supported. [root@fedora37 ~]# perf record iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 46362 [ 6] local 192.168.122.163 port 5201 connected to 192.168.122.1 port 46374 [ ID] Interval Transfer Bitrate [...] [ 6] 12.00-13.00 sec 3.18 GBytes 27.3 Gbits/sec [ 6] 13.00-14.00 sec 3.17 GBytes 27.3 Gbits/sec [ 6] 14.00-15.00 sec 3.13 GBytes 26.9 Gbits/sec [ 6] 15.00-16.00 sec 3.17 GBytes 27.3 Gbits/sec [ 6] 16.00-17.00 sec 3.17 GBytes 27.2 Gbits/sec [ 6] 17.00-18.00 sec 3.14 GBytes 27.0 Gbits/sec [ 6] 18.00-19.00 sec 3.17 GBytes 27.2 Gbits/sec [ 6] 19.00-20.00 sec 3.12 GBytes 26.8 Gbits/sec [ 6] 20.00-20.04 sec 119 MBytes 25.5 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 6] 0.00-20.04 sec 59.4 GBytes 25.4 Gbits/sec receiver ----------------------------------------------------------- Passt is used to support VMs in containers, such as KubeVirt, and is also generally supported in libvirt/QEMU since release 9.2 / 7.2. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> Signed-off-by: Jon Paul Maloy <jmaloy(a)redhat.com> --- net/ipv4/tcp.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 53bcc17c91e4..e9d3b5bf2f66 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2310,6 +2310,7 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, int *cmsg_flags) { struct tcp_sock *tp = tcp_sk(sk); + size_t peek_offset; int copied = 0; u32 peek_seq; u32 *seq; @@ -2353,6 +2354,20 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, if (flags & MSG_PEEK) { peek_seq = tp->copied_seq; seq = &peek_seq; + if (!msg->msg_iter.__iov[0].iov_base) { + peek_offset = msg->msg_iter.__iov[0].iov_len; + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + if (msg->msg_iter.nr_segs <= 1) + goto out; + msg->msg_iter.nr_segs -= 1; + if (msg->msg_iter.count <= peek_offset) + goto out; + msg->msg_iter.count -= peek_offset; + if (len <= peek_offset) + goto out; + len -= peek_offset; + *seq += peek_offset; + } } target = sock_rcvlowat(sk, flags & MSG_WAITALL, len); -- 2.39.0

1 0

[RFC net-next v4] tcp: add support for read with offset when using MSG_PEEK
by Jon Maloy 11 Jan '24

11 Jan '24

When reading received messages from a socket with MSG_PEEK, we may want to read the contents with an offset, like we can do with pread/preadv() when reading files. Currently, it is not possible to do that. In this commit, we allow the user to set iovec.iov_base in the first vector entry to NULL. This tells the socket to skip the first entry, hence letting the iov_len field of that entry indicate the offset value. This way, there is no need to add any new arguments or flags. In the iperf3 log examples shown below, we can observe a throughput improvement of ~15 % in the direction host->namespace when using the protocol splicer 'pasta' (https://passt.top). This is a consistent result. pasta(1) and passt(1) implement user-mode networking for network namespaces (containers) and virtual machines by means of a translation layer between Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo). Received, pending TCP data to the container/guest is kept in kernel buffers until acknowledged, so the tool routinely needs to fetch new data from socket, skipping data that was already sent. At the moment this is implemented using a dummy buffer passed to recvmsg(). With this change, we don't need a dummy buffer and the related buffer copy (copy_to_user()) anymore. passt and pasta are supported in KubeVirt and libvirt/qemu. jmaloy@lubu:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset not supported by kernel. jmaloy@lubu:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 44822 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 44832 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.02 GBytes 8.78 Gbits/sec [ 5] 1.00-2.00 sec 1.06 GBytes 9.08 Gbits/sec [ 5] 2.00-3.00 sec 1.07 GBytes 9.15 Gbits/sec [ 5] 3.00-4.00 sec 1.10 GBytes 9.46 Gbits/sec [ 5] 4.00-5.00 sec 1.03 GBytes 8.85 Gbits/sec [ 5] 5.00-6.00 sec 1.10 GBytes 9.44 Gbits/sec [ 5] 6.00-7.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 7.00-8.00 sec 1.07 GBytes 9.20 Gbits/sec [ 5] 8.00-9.00 sec 667 MBytes 5.59 Gbits/sec [ 5] 9.00-10.00 sec 1.03 GBytes 8.83 Gbits/sec [ 5] 10.00-10.04 sec 30.1 MBytes 6.36 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 10.3 GBytes 8.78 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated jmaloy@lubu:~/passt# logout [ perf record: Woken up 23 times to write data ] [ perf record: Captured and wrote 5.696 MB perf.data (35580 samples) ] jmaloy@lubu:~/passt$ jmaloy@lubu:~/passt$ perf record -g ./pasta --config-net -f MSG_PEEK with offset supported by kernel. jmaloy@lubu:~/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 40854 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 40862 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 1.00-2.00 sec 1.19 GBytes 10.2 Gbits/sec [ 5] 2.00-3.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 3.00-4.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 4.00-5.00 sec 1.20 GBytes 10.3 Gbits/sec [ 5] 5.00-6.00 sec 1.14 GBytes 9.80 Gbits/sec [ 5] 6.00-7.00 sec 1.17 GBytes 10.0 Gbits/sec [ 5] 7.00-8.00 sec 1.12 GBytes 9.61 Gbits/sec [ 5] 8.00-9.00 sec 1.13 GBytes 9.74 Gbits/sec [ 5] 9.00-10.00 sec 1.26 GBytes 10.8 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 11.8 GBytes 10.1 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated logout [ perf record: Woken up 20 times to write data ] [ perf record: Captured and wrote 5.040 MB perf.data (33411 samples) ] jmaloy@lubu:~/passt$ The perf record confirms this result. Below, we can observe that the CPU spends significantly less time in the function ____sys_recvmsg() when we have offset support. Without offset support: ---------------------- jmaloy@lubu:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 46.32% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg With offset support: ---------------------- jmaloy@lubu:~/passt$ perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i perf.data | head -1 27.24% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v3: Made changes suggested by Stefano Brivio: - Added perf result to commit log - Separated parameter sanity tests from code logics v4: - Simplified sanity test further. 'iov_iter.count' is caclulated as the sum of the segment sizes in ___sys_recvmsg()->recvmsg_copy_msghdr()->copy_msghdr_from_user()->__import_iovec()->iov_iter_init() 'len' is the same as iov_iter.count, as returnrd in sock_recvmsg_nosec()->msg_data_left()->iov_iter_count() Hence, iov[0].iov_len cannot be larger than any of those, and no additional testing is necessary. - Improved description of passt/pasta in commit log - Some cosmetic changes to the iperf3/perf output --- net/ipv4/tcp.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index ff6838ca2e58..50dc997b82f9 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2353,6 +2353,20 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, if (flags & MSG_PEEK) { peek_seq = tp->copied_seq; seq = &peek_seq; + if (!msg->msg_iter.__iov[0].iov_base) { + size_t peek_offset; + + if (msg->msg_iter.nr_segs < 2) { + err = -EINVAL; + goto out; + } + peek_offset = msg->msg_iter.__iov[0].iov_len; + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + msg->msg_iter.nr_segs -= 1; + msg->msg_iter.count -= peek_offset; + len -= peek_offset; + *seq += peek_offset; + } } target = sock_rcvlowat(sk, flags & MSG_WAITALL, len); -- 2.42.0

2 2

[RFC net-next v3] tcp: add support for read with offset when using MSG_PEEK
by Jon Maloy 10 Jan '24

10 Jan '24

When reading received messages from a socket with MSG_PEEK, we may want to read the contents with an offset, like we can do with pread/preadv() when reading files. Currently, it is not possible to do that. In this commit, we allow the user to set iovec.iov_base in the first vector entry to NULL. This tells the socket to skip the first entry, hence letting the iov_len field of that entry indicate the offset value. This way, there is no need to add any new arguments or flags. In the iperf3 logs examples shown below, we can observe a throughput improvement of ~15 % in the direction host->namespace when using the protocol splicer 'pasta' (https://passt.top). This is a consistent result. 'passt' is a tool used to support VMs in containers, such as KubeVirt, and is also generally supported in libvirt/QEMU since release 9.2 / 7.2. 'pasta' is the pure namespace variety of the same tool. jmaloy@lubu:~/passt/passt$ ../passt//net/tools/perf/perf record -g ./pasta --config-net -f MSG_PEEK with offset not supported by kernel. root@lubu:~/passt/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 44822 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 44832 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.02 GBytes 8.78 Gbits/sec [ 5] 1.00-2.00 sec 1.06 GBytes 9.08 Gbits/sec [ 5] 2.00-3.00 sec 1.07 GBytes 9.15 Gbits/sec [ 5] 3.00-4.00 sec 1.10 GBytes 9.46 Gbits/sec [ 5] 4.00-5.00 sec 1.03 GBytes 8.85 Gbits/sec [ 5] 5.00-6.00 sec 1.10 GBytes 9.44 Gbits/sec [ 5] 6.00-7.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 7.00-8.00 sec 1.07 GBytes 9.20 Gbits/sec [ 5] 8.00-9.00 sec 667 MBytes 5.59 Gbits/sec [ 5] 9.00-10.00 sec 1.03 GBytes 8.83 Gbits/sec [ 5] 10.00-10.04 sec 30.1 MBytes 6.36 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 10.3 GBytes 8.78 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated root@lubu:~/passt/passt# logout [ perf record: Woken up 23 times to write data ] [ perf record: Captured and wrote 5.696 MB perf.data (35580 samples) ] jmaloy@lubu:~/passt/passt$ jmaloy@lubu:~/passt/passt$ /home/jmaloy/passt//net/tools/perf/perf record -g ./pasta --config-net -f MSG_PEEK with offset supported by kernel. root@lubu:~/passt/passt# iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.122.1, port 40854 [ 5] local 192.168.122.180 port 5201 connected to 192.168.122.1 port 40862 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 1.00-2.00 sec 1.19 GBytes 10.2 Gbits/sec [ 5] 2.00-3.00 sec 1.22 GBytes 10.5 Gbits/sec [ 5] 3.00-4.00 sec 1.11 GBytes 9.56 Gbits/sec [ 5] 4.00-5.00 sec 1.20 GBytes 10.3 Gbits/sec [ 5] 5.00-6.00 sec 1.14 GBytes 9.80 Gbits/sec [ 5] 6.00-7.00 sec 1.17 GBytes 10.0 Gbits/sec [ 5] 7.00-8.00 sec 1.12 GBytes 9.61 Gbits/sec [ 5] 8.00-9.00 sec 1.13 GBytes 9.74 Gbits/sec [ 5] 9.00-10.00 sec 1.26 GBytes 10.8 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 11.8 GBytes 10.1 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated logout [ perf record: Woken up 20 times to write data ] [ perf record: Captured and wrote 5.040 MB perf.data (33411 samples) ] jmaloy@lubu:~/passt/passt$ The perf record confirms this result. Below, we can observe that the CPU spends significantly less time in the function ____sys_recvmsg() when we have offset support. Without offset support: ---------------------- jmaloy@lubu:~/passt/net/tools/perf$ ./perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i /home/jmaloy/passt/passt/perf.data | head -1 46.32% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg jmaloy@lubu:~$ With offset support: ---------------------- jmaloy@lubu:~/passt/net/tools/perf$ ./perf report -q --symbol-filter=do_syscall_64 -p ____sys_recvmsg -x --stdio -i /home/jmaloy/passt/passt/perf.data | head -1 27.24% 0.00% passt.avx2 [kernel.vmlinux] [k] do_syscall_64 ____sys_recvmsg jmaloy@lubu:~$ Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v3: Made changes suggested by Stefano Brivio: - Added perf result to commit log - Separated parameter sanity tests from code logics Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- net/ipv4/tcp.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index ff6838ca2e58..007b56dfc9e0 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2310,6 +2310,7 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, int *cmsg_flags) { struct tcp_sock *tp = tcp_sk(sk); + size_t peek_offset; int copied = 0; u32 peek_seq; u32 *seq; @@ -2353,6 +2354,18 @@ static int tcp_recvmsg_locked(struct sock *sk, struct msghdr *msg, size_t len, if (flags & MSG_PEEK) { peek_seq = tp->copied_seq; seq = &peek_seq; + if (!msg->msg_iter.__iov[0].iov_base) { + peek_offset = msg->msg_iter.__iov[0].iov_len; + if (peek_offset >= len || msg->msg_iter.nr_segs <= 1) { + err = -EINVAL; + goto out; + } + msg->msg_iter.__iov = &msg->msg_iter.__iov[1]; + msg->msg_iter.nr_segs -= 1; + msg->msg_iter.count -= peek_offset; + len -= peek_offset; + *seq += peek_offset; + } } target = sock_rcvlowat(sk, flags & MSG_WAITALL, len); -- 2.42.0

2 1