<feed xmlns='http://www.w3.org/2005/Atom'>
<title>passt/udp.c, branch bug209</title>
<subtitle>Plug A Simple Socket Transport</subtitle>
<link rel='alternate' type='text/html' href='https://passt.top/passt/'/>
<entry>
<title>udp: Improve messages for errors getting errors</title>
<updated>2026-06-22T07:13:46+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-06-19T15:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=edeb2a26c663085b3eae0a7eac6eb011a21ae7c3'/>
<id>edeb2a26c663085b3eae0a7eac6eb011a21ae7c3</id>
<content type='text'>
If udp_sock_recverr() gets an error retrieving the error queue, or
udp_sock_errs() gets an error reading the SO_ERROR sockopt, we log a
message with err_perror(),

That severity is reasonable - this is something going unexpectedly wrong
host side, not merely a connection getting shut down because we hit a
network error.  However, the messages can be made more useful by linking
them to the specific flow, and safer by ratelimiting them.

Remove the places where we included the numerical value of the socket fd:
that's rarely useful, especially now that we have the context about the
flow the fd belonged to.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If udp_sock_recverr() gets an error retrieving the error queue, or
udp_sock_errs() gets an error reading the SO_ERROR sockopt, we log a
message with err_perror(),

That severity is reasonable - this is something going unexpectedly wrong
host side, not merely a connection getting shut down because we hit a
network error.  However, the messages can be made more useful by linking
them to the specific flow, and safer by ratelimiting them.

Remove the places where we included the numerical value of the socket fd:
that's rarely useful, especially now that we have the context about the
flow the fd belonged to.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>flow, treewide: Promote priority of selected flow-linked messages</title>
<updated>2026-06-22T07:13:46+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-06-19T15:26:25+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=74863b01d304beda59d7a7bc9cfa887683fedd95'/>
<id>74863b01d304beda59d7a7bc9cfa887683fedd95</id>
<content type='text'>
Most of out flow specific log messages are debug level for fear of flooding
the logs, even when they report real error conditions that might be off
significance.

Now that we have the mechanisms for log message rate limiting, we can do
better.  Promote many flow related messages to warning or error level, with
rate limiting.  While we're there add ratelimiting to a handful of existing
warning or error level messages.

They general heuristic is to promote messages that report a failure which
is not something that should be triggered by the guest doing something
weird.  This mostly means failures from socket operations we expect to be
legitimate.

Adding the ratelimiting means plumbing the 'now' timestamp through much
more of the code, hence the large churn.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most of out flow specific log messages are debug level for fear of flooding
the logs, even when they report real error conditions that might be off
significance.

Now that we have the mechanisms for log message rate limiting, we can do
better.  Promote many flow related messages to warning or error level, with
rate limiting.  While we're there add ratelimiting to a handful of existing
warning or error level messages.

They general heuristic is to promote messages that report a failure which
is not something that should be triggered by the guest doing something
weird.  This mostly means failures from socket operations we expect to be
legitimate.

Adding the ratelimiting means plumbing the 'now' timestamp through much
more of the code, hence the large churn.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>flow: Include flow details with higher priority log messages</title>
<updated>2026-06-22T07:13:46+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-06-19T15:26:23+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=780ba8a55feb99feb11c3277b2cb7d3222ec7872'/>
<id>780ba8a55feb99feb11c3277b2cb7d3222ec7872</id>
<content type='text'>
Currently flow_log() and related functions / macros have a 'details'
parameter which indicates whether to add extra messages with details of the
flow's addresses.  This is still a bit awkward to invoke, and only used in
a few places.  Change the logic, to automatically include the details if
and only if the log priority is greater than LOG_DEBUG.

Rationale:

If at debug log level, there are already a bunch of debug messages tracking
the flow life cycle, which include those details (we make sure to retain
those).  It's usually pretty easy to cross reference a specific flow debug
message with the flow's history including the details.

If at higher log level, and we generate a flow-connected error or warning
we don't have those life cycle messages.  So, just giving the flow index
doesn't really tell you anything about which flow tripped the error.
Adding the address details make the error message significantly more
useful.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently flow_log() and related functions / macros have a 'details'
parameter which indicates whether to add extra messages with details of the
flow's addresses.  This is still a bit awkward to invoke, and only used in
a few places.  Change the logic, to automatically include the details if
and only if the log priority is greater than LOG_DEBUG.

Rationale:

If at debug log level, there are already a bunch of debug messages tracking
the flow life cycle, which include those details (we make sure to retain
those).  It's usually pretty easy to cross reference a specific flow debug
message with the flow's history including the details.

If at higher log level, and we generate a flow-connected error or warning
we don't have those life cycle messages.  So, just giving the flow index
doesn't really tell you anything about which flow tripped the error.
Adding the address details make the error message significantly more
useful.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>flow: Regularise flow specific logging helpers</title>
<updated>2026-06-22T07:13:46+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-06-19T15:26:21+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=d66a3f18138f94a3a7f8674d75551e7a844a1308'/>
<id>d66a3f18138f94a3a7f8674d75551e7a844a1308</id>
<content type='text'>
flow.h has a collection of logging helpers that automatically include
information about a specific flow.  Which variants are present are a bit
ad-hoc, based on what we happened to want use (e.g. there are no
LOG_WARNING level versions, at present).  There's also a rather awkward
and only occasionally used flow_log_details_() helper to print additional
log messages with more details of the flow (basically its addresses).
It's particularly awkward to try to combine that with ratelimiting.

Re-organise this to be based around a flow_log__() internal helper, which
has bool parameters to include strerror() / perror information and/or
the extra details.  Add wrapper macros for all combinations of perror,
ratelimiting and DEBUG/WARNING/ERR priorities.

Be a little more consistent about parameter order between the various
functions / macros / wrappers while we're at it.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
flow.h has a collection of logging helpers that automatically include
information about a specific flow.  Which variants are present are a bit
ad-hoc, based on what we happened to want use (e.g. there are no
LOG_WARNING level versions, at present).  There's also a rather awkward
and only occasionally used flow_log_details_() helper to print additional
log messages with more details of the flow (basically its addresses).
It's particularly awkward to try to combine that with ratelimiting.

Re-organise this to be based around a flow_log__() internal helper, which
has bool parameters to include strerror() / perror information and/or
the extra details.  Add wrapper macros for all combinations of perror,
ratelimiting and DEBUG/WARNING/ERR priorities.

Be a little more consistent about parameter order between the various
functions / macros / wrappers while we're at it.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fwd, pif: Remove duplicated logic between tcp_listen() and udp_listen()</title>
<updated>2026-06-16T21:49:57+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-06-16T01:09:35+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=50e3dcc44074dea26ed8486f65aa02d1dc2291ec'/>
<id>50e3dcc44074dea26ed8486f65aa02d1dc2291ec</id>
<content type='text'>
tcp_listen() and udp_listen() have only some simple logic around a call to
pif_listen(), and it's basically identical in each case.  If we move the
common logic into pif_listen() we can then remove {tcp,udp}_listen()
entirely, with their caller in fwd_sync_one() calling pif_listen()
directly.

We also move the logic converting from a protocol id to an epoll type from
fwd_sync_one() into pif_listen().  It's a bit arbitrary, but seems slightly
nicer that way.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tcp_listen() and udp_listen() have only some simple logic around a call to
pif_listen(), and it's basically identical in each case.  If we move the
common logic into pif_listen() we can then remove {tcp,udp}_listen()
entirely, with their caller in fwd_sync_one() calling pif_listen()
directly.

We also move the logic converting from a protocol id to an epoll type from
fwd_sync_one() into pif_listen().  It's a bit arbitrary, but seems slightly
nicer that way.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6()</title>
<updated>2026-05-26T10:17:07+00:00</updated>
<author>
<name>Laurent Vivier</name>
<email>lvivier@redhat.com</email>
</author>
<published>2026-05-20T09:55:26+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=dec66c02b5e43e0ef809afa47e1008e143a01250'/>
<id>dec66c02b5e43e0ef809afa47e1008e143a01250</id>
<content type='text'>
Change udp_update_hdr4() and udp_update_hdr6() to take an iov_tail
pointing at the UDP frame instead of a contiguous udp_payload_t buffer
and explicit data length.  This lets vhost-user pass scatter-gather
virtqueue buffers directly without an intermediate copy.

The UDP header is built into a local struct udphdr and written back with
IOV_PUSH_HEADER().  On the tap side, udp_tap_prepare() wraps the
existing udp_payload_t in a two-element iov to match the new interface.

Signed-off-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change udp_update_hdr4() and udp_update_hdr6() to take an iov_tail
pointing at the UDP frame instead of a contiguous udp_payload_t buffer
and explicit data length.  This lets vhost-user pass scatter-gather
virtqueue buffers directly without an intermediate copy.

The UDP header is built into a local struct udphdr and written back with
IOV_PUSH_HEADER().  On the tap side, udp_tap_prepare() wraps the
existing udp_payload_t in a two-element iov to match the new interface.

Signed-off-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>checksum: Pass explicit L4 length to checksum functions</title>
<updated>2026-05-19T23:21:38+00:00</updated>
<author>
<name>Laurent Vivier</name>
<email>lvivier@redhat.com</email>
</author>
<published>2026-05-13T11:52:14+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=aa78f63c3c9491a9cad9f3c805a59748bd8c1ae2'/>
<id>aa78f63c3c9491a9cad9f3c805a59748bd8c1ae2</id>
<content type='text'>
The iov_tail passed to csum_iov_tail() may contain padding or trailing
data beyond the actual L4 payload.  Rather than relying on
iov_tail_size() to determine how many bytes to checksum, pass the
length explicitly so that only the relevant payload bytes are included
in the checksum computation.

Signed-off-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Reviewed-by: Jon Maloy &lt;jmaloy@redhat.com&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The iov_tail passed to csum_iov_tail() may contain padding or trailing
data beyond the actual L4 payload.  Rather than relying on
iov_tail_size() to determine how many bytes to checksum, pass the
length explicitly so that only the relevant payload bytes are included
in the checksum computation.

Signed-off-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Reviewed-by: Jon Maloy &lt;jmaloy@redhat.com&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tap, tcp, udp: Use rate-limited logging</title>
<updated>2026-04-15T18:59:35+00:00</updated>
<author>
<name>Anshu Kumari</name>
<email>anskuma@redhat.com</email>
</author>
<published>2026-04-10T10:37:37+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=5ac9cf11a512e6d54c94a2e6a7ddaabc10cb5b9b'/>
<id>5ac9cf11a512e6d54c94a2e6a7ddaabc10cb5b9b</id>
<content type='text'>
Now that rate-limited logging macros are available, promote several
debug messages to higher severity levels.  These messages were
previously kept at debug to prevent guests from flooding host
logs, but with rate limiting they can safely be made visible in
normal operation.

In tap.c, refactor tap4_is_fragment() to use warn_ratelimit() instead
of its ad-hoc rate limiting, and promote the guest MAC address change
message to info level.

In tcp.c, promote the invalid TCP SYN endpoint message to warn level.

In udp.c, promote dropped datagram messages to warn level, and
rate-limit the unrecoverable socket error message.

In udp_flow.c, promote flow allocation failures to err_ratelimit.

Link: https://bugs.passt.top/show_bug.cgi?id=134
Signed-off-by: Anshu Kumari &lt;anskuma@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that rate-limited logging macros are available, promote several
debug messages to higher severity levels.  These messages were
previously kept at debug to prevent guests from flooding host
logs, but with rate limiting they can safely be made visible in
normal operation.

In tap.c, refactor tap4_is_fragment() to use warn_ratelimit() instead
of its ad-hoc rate limiting, and promote the guest MAC address change
message to info level.

In tcp.c, promote the invalid TCP SYN endpoint message to warn level.

In udp.c, promote dropped datagram messages to warn level, and
rate-limit the unrecoverable socket error message.

In udp_flow.c, promote flow allocation failures to err_ratelimit.

Link: https://bugs.passt.top/show_bug.cgi?id=134
Signed-off-by: Anshu Kumari &lt;anskuma@redhat.com&gt;
Reviewed-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>treewide: Spell ASSERT() as assert()</title>
<updated>2026-03-20T20:05:29+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-03-19T06:11:43+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=bc872d91765dfd6ff34b0e9a34bce410fac1cef3'/>
<id>bc872d91765dfd6ff34b0e9a34bce410fac1cef3</id>
<content type='text'>
The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include &lt;assert.h&gt; to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include &lt;assert.h&gt; to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fwd: Unify TCP and UDP forwarding tables</title>
<updated>2026-03-11T21:11:30+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2026-03-11T12:03:11+00:00</published>
<link rel='alternate' type='text/html' href='https://passt.top/passt/commit/?id=d460ca3236bafa724686a5ad7f585d70962f7373'/>
<id>d460ca3236bafa724686a5ad7f585d70962f7373</id>
<content type='text'>
Currently TCP and UDP each have their own forwarding tables.  This is
awkward in a few places, where we need switch statements to select the
correct table.  More importantly, it would make things awkward and messy to
extend to other protocols in future, which we're likely to want to do.

Merge the TCP and UDP tables into a single table per (source) pif, with the
protocol given in each rule entry.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently TCP and UDP each have their own forwarding tables.  This is
awkward in a few places, where we need switch statements to select the
correct table.  More importantly, it would make things awkward and messy to
extend to other protocols in future, which we're likely to want to do.

Merge the TCP and UDP tables into a single table per (source) pif, with the
protocol given in each rule entry.

Signed-off-by: David Gibson &lt;david@gibson.dropbear.id.au&gt;
Signed-off-by: Stefano Brivio &lt;sbrivio@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
