passt/tcp_vu.c, branch 2026_01_17.81c97f6

tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum)

2025-12-08T03:47:46+00:00

For both TCP and UDP, instead of just expecting the first provided
buffer to be large enough to contain the headers we need (from 42
bytes for UDP data over IPv4 to 82 bytes for TCP with options over
IPv6), change that assumption to make sure that buffers are anyway
at least ETH_ZLEN-sized buffers (60 bytes).

This looks reasonable because there are no known vhost-user
hypervisor implementations that would give us smaller buffers than
that, and we would anyway hit an assertion failure with IPv6 if we
ever had less than 60 bytes per buffer.

At this point, all we need to do is to pad the first (and only)
buffer, should data and headers use less than that.

Link: https://bugs.passt.top/show_bug.cgi?id=166
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

tcp: forward external source MAC address through tap interface

2025-10-30T11:01:01+00:00

We forward the incoming mac address through the tap interface when
receiving incoming packets from network local hosts.

This is a part of the solution to bug
https://bugs.passt.top/show_bug.cgi?id=120

Signed-off-by: Jon Maloy 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp: Fix ACK sequence on FIN to tap

2025-10-07T20:22:27+00:00

If we reach end-of-file on a socket (or get EPOLLRDHUP / EPOLLHUP) and
send a FIN segment to the guest / container acknowledging a sequence
number that's behind what we received so far, we won't have any
further trigger to send an updated ACK segment, as we are now
switching the epoll socket monitoring to edge-triggered mode.

To avoid this situation, in tcp_update_seqack_wnd(), we set the next
acknowledgement sequence to the current observed sequence, regardless
of what was acknowledged socket-side.

However, we don't necessarily call tcp_update_seqack_wnd() before
sending the FIN segment, which might potentially lead to a situation,
not observed in practice, where we unnecessarily cause a
retransmission at some point after our FIN segment.

Avoid that by setting the ACK sequence to whatever we received from
the container / guest, before sending a FIN segment and switching to
EPOLLET.

Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

Reduce tcp_buf_discard size

2025-09-11T15:09:03+00:00

On kernels without SO_PEEK_OFF, a 16MB static buffer is used to
discard sent data. This patch reduces the buffer to 1MB.

Larger discards are now handled by using multiple iovec entries
pointing to the same 1MB buffer.

Signed-off-by: Xun Gu 
[sbrivio: Drop stray whitespace after BUF_DISCARD_SIZE define]
Signed-off-by: Stefano Brivio

tcp_vu: Pass virtqueue pointer to tcp_vu_sock_recv()

2025-09-09T19:14:35+00:00

Pass the virtqueue pointer to tcp_vu_sock_recv() to enable proper
queue selection for multiqueue support. This ensures that received
packets are processed on the same virtqueue as the caller.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

style: Fix 'Return' comment style

2025-07-18T17:19:24+00:00

We always use imperative (no 'Returns:'), no tab after the ':' and
only one space, the first character is always lowercase.

This is fixed with:

 sed -i "s/Returns:/Return:/;s/Return:    /Return: /;s/Return:  */Return: /;s/Return: \([A-Z]\)/Return: \L\1/" *.[ch]

And manually updated to fix alignment of multiline comment and words
that must keep uppercase (like IPv4, TCP, UDP, Layer-4).

Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

Correct various function comment headers

2025-06-04T10:32:04+00:00

This commit refines function comment headers for improved accuracy
and consistency. Key changes include:

- Corrected parameter/return descriptions (e.g., `logtime`, `__daemon`).
- Added missing and removed incorrect parameter documentation (e.g.,
  `tcp_vu_sock_recv`, `ndp`).
- Standardized comments to the `/** ... */` style for functions
  like `udp_flow_close` and `ns_enter`.
- Ensured function names in comments consistently use `()`.
- Addressed minor typos and updated comments for renamed functions.

Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

tcp, flow: Better use flow specific logging heleprs

2025-03-14T22:40:40+00:00

A number of places in the TCP code use general logging functions, instead
of the flow specific ones.  That includes a few older ones as well as many
places in the new migration code.  Thus they either don't identify which
flow the problem happened on, or identify it in a non-standard way.

Convert many of these to use the existing flow specific helpers.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp_vu: head_cnt need not be global

2025-02-18T10:28:37+00:00

head_cnt is a global variable which tracks how many entries in head[] are
currently used.  The fact that it's global obscures the fact that the
lifetime over which it has a meaningful value is quite short: a single
call to of tcp_vu_data_from_sock().

Make it a local to tcp_vu_data_from_sock() to make that lifetime clearer.
We keep the head[] array global for now - although technically it has the
same valid lifetime - because it's large enough we might not want to put
it on the stack.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

tcp_vu: Fix off-by one in header count array adjustment

2025-02-12T18:44:25+00:00

head_cnt represents the number of frames we're going to forward to the
guest in tcp_vu_sock_recv(), each of which could require multiple
buffers ("elements").  We initialise it with as many frames as we can
find space for in vu buffers, and we then need to adjust it down to
the number of frames we actually (partially) filled.

We adjust it down based on number of individual buffers used by the
data from recvmsg().  At this point 'i' is *one greater than* that
number of buffers, so we need to discard all (unused) frames with a
buffer index >= i, instead of > i.

Reported-by: David Gibson 
[david: Contributed actual commit message]
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio