passt/tap.h, branch bug205

Add missing includes to headers

2026-03-04T16:39:57+00:00

Support build systems like bazel that check that headers are
self-contained.

Also update includes so that clang-include-cleaner succeeds.

Tested with:
clang-include-cleaner-19 --extra-arg=-D_GNU_SOURCE --extra-arg=-DPAGE_SIZE=4096 --extra-arg=-DVERSION=\"git\" --extra-arg=-DHAS_GETRANDOM *.h *.c

Signed-off-by: Peter Foley 
Signed-off-by: Stefano Brivio

tcp: Move tap header update out of tcp_fill_headers()

2026-02-15T01:52:42+00:00

tcp_fill_headers() currently calls tap_hdr_update() to set the frame
length in the tap-specific header.  This is backend-specific: the tap
backend needs this for its frame length header, but the vhost-user
backend passes NULL for the tap header and doesn't use it at all.

Remove the tap_hdr parameter from tcp_fill_headers() and instead return
the computed L2 frame length.  The tap backend caller,
tcp_l2_buf_fill_headers(), now calls tap_hdr_update() itself with the
returned length.  The vhost-user callers, tcp_vu_send_flag() and
tcp_vu_prepare(), no longer need to pass a NULL tap header.

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

arp/ndp: don't send messages on uninitialized tap interface

2025-11-27T21:29:25+00:00

When running pasta without --config-net, the tap interface is opened
and assigned a valid file descriptor, but intentionally not brought
up in the namespace. This is the expected behavior when the user wants
to configure the namespace manually.

However, in PASTA mode the code is attempting to send ARP announcements
and NDP messages (initial requests and unsolicited NAs) based solely on
whether c->fd_tap is valid, without checking if the interface actually
is up and ready to transmit. This results in send failures, and when
debug is activated (pasta -d) we see error printouts for these early
messages.

We now add new function tap_is_ready() which checks both conditions:
- Whether fd_tap is valid (all modes)
- Whether the tap interface is up (pasta mode only). In this mode, we
  use the existing c->pasta_conf_ns flag, which indicates whether
  pasta_ns_conf() configured and brought up the interface. This test
  is simple, and good enough for now.

We update all functions that send unsolicited ARP/NDP messages to
check with the new function before making any send attempt.

This eliminates spurious send errors when starting pasta without
--config-net, while preserving correct behavior when the interface
is properly initialized.

Signed-off-by: Jon Maloy 
Signed-off-by: Stefano Brivio

icmp: let icmp use mac address from flowside structure

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

Even ICMP needs to be updated to use the external MAC address instead
of just the own tap address when applicable. We do that here.

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

tap: change signature of function tap_push_l2h()

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

In the next commit it must be possible for the callers of function
tap_push_l2h() to specify which source MAC address should be
added to the ethernet header sent over the tap interface. As a
preparation, we now add a new argument to that function, still
without any logical changes.

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

packet: Refactor vhost-user memory region handling

2025-09-03T18:43:48+00:00

This patch refactors the handling of vhost-user memory regions by
introducing a new `struct vdev_memory` to encapsulate the regions
array and their count (`nregions`) within the main `vu_dev` structure.

This new `vdev_memory` structure is then passed to the packet pool by
re-using the existing `p->buf` field. A `p->buf_size` of 0 indicates
that `p->buf` holds a pointer to `struct vdev_memory` instead of a
regular packet buffer. A new helper, `get_vdev_memory()`, is added to
abstract this access pattern.

Previous implementation was using a marker at the end of the memory
regions array. We can now uses all the slots.

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

tap: Use iov_tail with tap_add_packet()

2025-09-03T18:42:20+00:00

Use IOV_PEEK_HEADER() to get the ethernet header from the iovec.

Move the workaround about multiple iovec array from vu_handle_tx() to
tap_add_packet(). Removing the offset out of the iovec array should
reduce the iovec count to 1.

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

tap: Make size of pool_tap[46] purely a tuning parameter

2025-03-20T19:33:09+00:00

Currently we attempt to size pool_tap[46] so they have room for the maximum
possible number of packets that could fit in pkt_buf (TAP_MSGS).  However,
the calculation isn't quite correct: TAP_MSGS is based on ETH_ZLEN (60) as
the minimum possible L2 frame size.  But ETH_ZLEN is based on physical
constraints of Ethernet, which don't apply to our virtual devices.  It is
possible to generate a legitimate frame smaller than this, for example an
empty payload UDP/IPv4 frame on the 'pasta' backend is only 42 bytes long.

Further more, the same limit applies for vhost-user, which is not limited
by the size of pkt_buf like the other backends.  In that case we don't even
have full control of the maximum buffer size, so we can't really calculate
how many packets could fit in there.

If we exceed do TAP_MSGS we'll drop packets, not just use more batches,
which is moderately bad.  The fact that this needs to be sized just so for
correctness not merely for tuning is a fairly non-obvious coupling between
different parts of the code.

To make this more robust, alter the tap code so it doesn't rely on
everything fitting in a single batch of TAP_MSGS packets, instead breaking
into multiple batches as necessary.  This leaves TAP_MSGS as purely a
tuning parameter, which we can freely adjust based on performance measures.

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

pcap: Correctly set snaplen based on tap backend type

2025-03-12T22:08:33+00:00

The pcap header includes a value indicating how much of each frame is
captured.  We always capture the entire frame, so we want to set this to
the maximum possible frame size.  Currently we do that by setting it to
ETH_MAX_MTU, but that's a confusingly named constant which might not always
be correct depending on the details of our tap backend.

Instead add a tap_l2_max_len() function that explicitly returns the maximum
frame size for the current mode and use that to set snaplen.  While we're
there, there's no particular need for the pcap header to be defined in a
global; make it local to pcap_init() instead.

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