public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Ammar Yasser <aerosound161@gmail.com>
Cc: passt-dev@passt.top, eperezma@redhat.com
Subject: Re: [RFC v3 7/8] pasta: Implement pasta vhost TX (pasta->guest) prerequisites
Date: Thu, 13 Aug 2026 12:01:59 +1000	[thread overview]
Message-ID: <an0liZLGMM50smpg@zatzit> (raw)
In-Reply-To: <DKN6NLEIHADC.36U96ISU646@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 13966 bytes --]

On Wed, Aug 12, 2026 at 09:39:33PM +0300, Ammar Yasser wrote:
> On Mon Aug 10, 2026 at 12:01 PM EEST, David Gibson wrote:
> > On Sun, Aug 02, 2026 at 01:21:54PM +0000, Ammar Yasser wrote:
> >> - tap_send_single was changed to directly call
> >>   tap_send_frames_passt/pasta instead of relying on tap_send_frames
> >>   because protocols that use tap_send_single won't use vhost
> >>   acceleration, only tcp and udp will. The function was also moved lower
> >>   in the file to by the time its called tap_send_frames_* functions are
> >>   defined and a forward declaration isn't needed
> >
> > Sorry, I'm not really following why the vhost change requires
> > tap_send_single() to bypass tap_send_frames().
> 
> In a previous review from you on the original work by Eugenio you said
> you don't want tap_send_frames to take a vhost boolean parameter because
> its a pasta only value to a function that is used by passt and pasta.
> If tap_send_single relies on tap_send_frames (assuming it takes no vhost
> bool), and deducing whether to use vhost or no is based on c->vhost then
> arp, icmp, ndp.. and other single send protos end up using vhost as
> well. which won't work since those protos don't have a concrete memory
> region i can make the kernel aware of.

Ah, I see.  This is the key point the commit message needs to explain:
some of the users of tap_send_single() *can't* use the vhost path,
because of the shared buffers.

> And obvioiusly doing a protocol
> check inside tap_send_frames is not super cool either.
> 
> Let me know your opinion on this!
> 
> >
> >> - extend udp_meta_t to instead of always carrying a tap_hdr, to carry a
> >>   union of a tap_hdr and a virtio_net header because if vhost is used
> >>   the will the latter type of header and then build an iov from this
> >>   virtio net header in udp.c
> >
> > In fact, the intended role of tap_hdr itself was to be a union of
> > whatever "below L2" headers we might need for all our backends.  It
> > was never very obvious because there was just the vnet_len (for the
> > qemu -net socket protocol) and nothing at all (for tuntap via the
> > chardev).  With vhost-user, in theory it should have gained a
> > virtio_net_mrg_rxbuf branch, but the vhost-user paths are different
> > enough that we never quite needed it.
> >
> > Here for vhost-kernel, though, we should add the virtio_net header
> > inside tap_hdr, rather than making a union including tap_hdr.
> > tap_hdr_iov() and tap_hdr_update() should be updated to handle that
> > case as well.
> 
> To make sure i understand, you're saying that tap_hdr itself should be a
> union of vnet_len and virtio_net_mrg_rxbuf ?

Yes.

> i don't disagree in
> principal,

(English usage nit: in this context it's "principle", not "principal")

> but will need to check that frame length accounting doesn't go
> wrong in any area as a consequence of this.

Right, doing this will certainly need some updating in places to
handle it.  I don't think it should be super hard, since it was
introduced with a future extension like this in mind.

Note that in a sense you can already think of tap_hdr as a union
between vnet_len (passt) and an empty structure (pasta).

> >> +/**
> >> + * tap_send_single() - Send a single frame
> >> + * @c:		Execution context
> >> + * @data:	Packet buffer
> >> + * @l2len:	Total L2 packet length
> >> + */
> >> +void tap_send_single(const struct ctx *c, const void *data, size_t l2len)
> >> +{
> >> +	uint8_t padded[ETH_ZLEN] = { 0 };
> >> +	struct iovec iov[2];
> >> +	size_t iovcnt = 0;
> >> +	int m = 0;
> >> +	uint32_t vnet_len;
> >> +
> >> +	if (l2len < ETH_ZLEN) {
> >> +		memcpy(padded, data, l2len);
> >> +		data = padded;
> >> +		l2len = ETH_ZLEN;
> >> +	}
> >> +
> >> +	vnet_len = htonl(l2len);
> >> +	switch (c->mode) {
> >> +	case MODE_PASST:
> >> +		/* create an iov for the length */
> >> +		iov[iovcnt] = IOV_OF_LVALUE(vnet_len);
> >> +		iovcnt++;
> >> +		/* create the data iov */
> >> +		iov[iovcnt].iov_base = (void *)data;
> >> +		iov[iovcnt].iov_len = l2len;
> >> +		iovcnt++;
> >> +		m = tap_send_frames_passt(c, iov, iovcnt, 1);
> >> +		break;
> >> +	case MODE_PASTA:
> >> +		/* don't create a length iov in the case of pasta */
> >> +		iov[iovcnt].iov_base = (void *)data;
> >> +		iov[iovcnt].iov_len = l2len;
> >> +		iovcnt++;
> >> +
> >> +		m = tap_send_frames_pasta(c, iov, iovcnt, 1, false);
> >
> > You explicitly disable vhost here, even if available.  As I've said
> > before, tap_send_single() is a slow path that doesn't really need
> > vhost acceleration.  However, there's also not really a reason *not*
> > to use vhost unless it simplifies things.  So far this seems to be
> > adding (slightly) complexity to avoid using vhost, and it's not clear
> > to me if there's a simplification elsewhere that makes it worth it.
> 
> As per above comment, its a correctness problem. single send protocols
> won't work with vhost in the current state, thats why i went the extra
> mile to avoid it. let me know if i am misunderstanding anything

Right, I missed that constraint.  Might be worth putting it in a
comment, since it's not necessarily obvious from this point in the code.

> 
> >
> >> +		break;
> >> +	case MODE_VU:
> >> +		m = vu_send_single(c, data, l2len);
> >> +		break;
> >> +	}
> >> +
> >> +	if (m < 1)
> >> +		debug("tap: failed to send a single frame");
> >> +
> >> +	pcap_multiple(iov, iovcnt, m,
> >> +	    c->mode == MODE_PASST ? sizeof(uint32_t) :
> >> +	    (c->fd_vhost != -1) ? VNET_HLEN : 0);
> >> +}
> >> +
> >>  /**
> >>   * tap_send_frames() - Send out multiple prepared frames
> >>   * @c:			Execution context
> >> @@ -523,7 +537,8 @@ size_t tap_send_frames(const struct ctx *c, const struct iovec *iov,
> >>  
> >>  	switch (c->mode) {
> >>  	case MODE_PASTA:
> >> -		m = tap_send_frames_pasta(c, iov, bufs_per_frame, nframes);
> >> +		/* use vhost in pasta sending only if the vhost setup was actually successful, indicated by a non-zero fd_vhost */
> >> +		m = tap_send_frames_pasta(c, iov, bufs_per_frame, nframes, ((c->fd_vhost != -1)));
> >>  		break;
> >>  	case MODE_PASST:
> >>  		m = tap_send_frames_passt(c, iov, bufs_per_frame, nframes);
> >> @@ -539,7 +554,8 @@ size_t tap_send_frames(const struct ctx *c, const struct iovec *iov,
> >>  		      nframes - m, nframes);
> >>  
> >>  	pcap_multiple(iov, bufs_per_frame, m,
> >> -		      c->mode == MODE_PASST ? sizeof(uint32_t) : 0);
> >> +	    c->mode == MODE_PASST ? sizeof(uint32_t) :
> >> +	    (c->fd_vhost != -1) ? VNET_HLEN : 0);
> >
> > Rather than this nested ?: expression we should make a helper that
> > gives the necessary length to exclude tap_hdr.  tap_hdr_iov() should
> > then use the same helper.
> 
> Noted. will do
> 
>  
> >> +static inline struct iovec iov_from_virtio_net_hdr(struct virtio_net_hdr_mrg_rxbuf *hdr)
> >> +{
> >> +    return (struct iovec){
> >> +            .iov_base = hdr,
> >> +            .iov_len = sizeof(*hdr),
> >> +    };
> >> +}
> >
> > As noted, this should become a new branch of tap_hdr_iov()...
> >
> >>  /**
> >>   * tcp_sock_iov_init() - Initialise scatter-gather L2 buffers for IPv4 sockets
> >>   * @c:		Execution context
> >> @@ -89,7 +98,14 @@ void tcp_sock_iov_init(const struct ctx *c)
> >>  	for (i = 0; i < TCP_FRAMES_MEM; i++) {
> >>  		struct iovec *iov = tcp_l2_iov[i];
> >>  
> >> -		iov[TCP_IOV_TAP] = tap_hdr_iov(c, &tcp_payload_tap_hdr[i]);
> >> +		/* If we are using pasta with vhost acceleration, the first entry in the tcp buffers
> >> +		 * should point to a virtio_net header, otherwise a tap header 
> >> +		 */		
> >> +		if ((c->fd_vhost != -1))
> >> +			iov[TCP_IOV_TAP] = iov_from_virtio_net_hdr(&tcp_payload_tap_hdr[i]);
> >> +		else 
> >> +			iov[TCP_IOV_TAP] = tap_hdr_iov(c, (struct tap_hdr *)&tcp_payload_tap_hdr[i]);
> >
> > ..absorbing this if.
> 
> So the if statement goes into tap_hdr_iov? ok noted
> 
> >
> >>  		iov[TCP_IOV_ETH].iov_len = sizeof(struct ethhdr);
> >>  		iov[TCP_IOV_PAYLOAD].iov_base = &tcp_payload[i];
> >>  		iov[TCP_IOV_ETH_PAD].iov_base = eth_pad;
> >> @@ -135,8 +151,7 @@ void tcp_payload_flush(const struct ctx *c, const struct timespec *now)
> >>  {
> >>  	size_t m;
> >>  
> >> -	m = tap_send_frames(c, &tcp_l2_iov[0][0], TCP_NUM_IOVS,
> >> -			    tcp_payload_used);
> >> +	m = tap_send_frames(c, &tcp_l2_iov[0][0], TCP_NUM_IOVS, tcp_payload_used);
> >>  	if (m != tcp_payload_used) {
> >>  		tcp_revert_seq(c, &tcp_frame_conns[m], &tcp_l2_iov[m],
> >>  			       tcp_payload_used - m, now);
> >> @@ -177,7 +192,7 @@ static void tcp_l2_buf_fill_headers(const struct ctx *c,
> >>  {
> >>  	struct iov_tail tail = IOV_TAIL(&iov[TCP_IOV_PAYLOAD], 1, 0);
> >>  	struct tcphdr th_storage, *th = IOV_REMOVE_HEADER(&tail, th_storage);
> >> -	struct tap_hdr *taph = iov[TCP_IOV_TAP].iov_base;
> >> +
> >>  	const struct flowside *tapside = TAPFLOW(conn);
> >>  	const struct in_addr *a4 = inany_v4(&tapside->oaddr);
> >>  	struct ethhdr *eh = iov[TCP_IOV_ETH].iov_base;
> >> @@ -192,7 +207,19 @@ static void tcp_l2_buf_fill_headers(const struct ctx *c,
> >>  
> >>  	l2len = tcp_fill_headers(c, conn, eh, ip4h, ip6h, th, &tail,
> >>  				 iov_tail_size(&tail), csum_flags, seq);
> >> -	tap_hdr_update(taph, l2len);
> >> +
> >> +	/* when in pasta mode, the length of the tap header iov is zero, so this
> >> +	 * l2len write doesn't do anything. But this function gets called from both
> >> +	 * pasta and passt. Make the l2len write in case we are in passt mode, denoted by
> >> +	 * fd_vhost being -1 since this field won't get initialized at all in passt.
> >> +	 */
> >> +	if (c->mode == MODE_PASST) {
> >> +		iov[TCP_IOV_TAP].iov_len = sizeof(struct tap_hdr);
> >> +		struct tap_hdr *taph = iov[TCP_IOV_TAP].iov_base;
> >> +		tap_hdr_update(taph, l2len);
> >> +	} else if (c->fd_vhost == -1) { /* pasta mode but without vhost */
> >> +		iov[TCP_IOV_TAP].iov_len = 0;
> >> +	}
> >
> > Similarly this if should go inside tap_hdr_update().
> >
> >>  }
> >>  
> >>  /**
> >> diff --git a/tcp_buf.h b/tcp_buf.h
> >> index c749038..da48cd0 100644
> >> --- a/tcp_buf.h
> >> +++ b/tcp_buf.h
> >> @@ -9,7 +9,7 @@
> >>  #include "tcp_conn.h"
> >>  #include "tcp_internal.h"
> >>  
> >> -void tcp_sock_iov_init();
> >> +void tcp_sock_iov_init(const struct ctx *c);
> >>  void tcp_payload_flush(const struct ctx *c, const struct timespec *now);
> >>  int tcp_buf_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn,
> >>  			   uint32_t already_sent, const struct timespec *now);
> >> @@ -20,7 +20,7 @@ int tcp_buf_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags,
> >>  #define TCP_FRAMES							   \
> >>  (c->mode == MODE_PASTA ? 1 : TCP_FRAMES_MEM)
> >>  
> >> -extern struct tap_hdr tcp_payload_tap_hdr[TCP_FRAMES_MEM];
> >> +extern struct virtio_net_hdr_mrg_rxbuf tcp_payload_tap_hdr[TCP_FRAMES_MEM];
> >>  extern struct ethhdr		tcp_eth_hdr[TCP_FRAMES_MEM];
> >>  extern struct tcp_payload_t	tcp_payload[TCP_FRAMES_MEM];
> >>  
> >> diff --git a/udp.c b/udp.c
> >> index d05ee66..5f90dce 100644
> >> --- a/udp.c
> >> +++ b/udp.c
> >> @@ -103,6 +103,7 @@
> >>  #include <time.h>
> >>  #include <arpa/inet.h>
> >>  #include <linux/errqueue.h>
> >> +#include <linux/virtio_net.h>
> >>  
> >>  #include "checksum.h"
> >>  #include "util.h"
> >> @@ -119,6 +120,18 @@
> >>  #include "udp_vu.h"
> >>  #include "epoll_ctl.h"
> >>  
> >> +/* UDP header and data for inbound messages */
> >> +struct udp_payload_t udp_payload[UDP_MAX_FRAMES];
> >> +
> >> +/* Ethernet headers for IPv4 and IPv6 frames */
> >> +struct ethhdr udp_eth_hdr[UDP_MAX_FRAMES];
> >> +
> >> +/* IOVs and msghdr arrays for receiving datagrams from sockets */
> >> +struct iovec	udp_iov_recv		[UDP_MAX_FRAMES];
> >> +struct mmsghdr	udp_mh_recv		[UDP_MAX_FRAMES];
> >> +
> >> +/* Pre-cooked headers for UDP packets */
> >> +struct udp_meta_t udp_meta[UDP_MAX_FRAMES];
> >
> > I'm slightly confused.  I see these added, but I don't see the
> > existing static declarations removed.  It's also not clear to me why
> > these need to become non-static.
> 
> The static declarations were removed in the second patch. This addition
> is misplaced, will fix.

Ok.

> But yeah they do need to be non static because of the need to share them
> with the kernel in virtio.c

Does that mean the *only* reference in virtio.c is just to get their
address/size to put into the shared memory table?  If that's the case
delegating to a helper within udp.c to register them into the table
seems like a better approach.

> >>  #define UDP_TIMEOUT	"/proc/sys/net/netfilter/nf_conntrack_udp_timeout"
> >>  #define UDP_TIMEOUT_STREAM	\
> >> @@ -216,7 +229,20 @@ static void udp_iov_init_one(const struct ctx *c, size_t i)
> >>  	*siov = IOV_OF_LVALUE(payload->data);
> >>  
> >>  	tiov[UDP_IOV_ETH] = IOV_OF_LVALUE(udp_eth_hdr[i]);
> >> -	tiov[UDP_IOV_TAP] = tap_hdr_iov(c, &meta->taph);
> >> +	/* if the vhost tap fd is initialized, this is a sign for us that
> >> +	 * we will be using virtio transport. make the iov that is supposed
> >> +	 * to point to a tap header point instead to a virtio_net_mrg_rxbuf
> >> +	 */
> >> +	if (c->fd_vhost != -1) {
> >> +		struct iovec vnet_iov = {
> >> +			.iov_base = (void *)(&meta->vnet_hdr),
> >> +			.iov_len = sizeof(meta->vnet_hdr)
> >> +		};
> >> +		tiov[UDP_IOV_TAP] = vnet_iov;
> >> +	} else {
> >> +		tiov[UDP_IOV_TAP] = tap_hdr_iov(c, &meta->taph);
> >> +	}
> >
> > Again, this logic should go inside tap_hdr_iov().
> 
> Got it.
> 

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-08-13  2:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 13:21 [RFC v3 0/8] Add vhost-net kernel support to pasta Ammar Yasser
2026-08-02 13:21 ` [RFC v3 1/8] tap: Move the tap_hdr file to a separate file Ammar Yasser
2026-08-07  5:40   ` David Gibson
2026-08-02 13:21 ` [RFC v3 2/8] udp,tcp: Make protocol specific buffers public Ammar Yasser
2026-08-07  5:56   ` David Gibson
2026-08-12 16:29     ` Ammar Yasser
2026-08-02 13:21 ` [RFC v3 3/8] conf: Add context fields, epoll types and the --vhost flag to pasta Ammar Yasser
2026-08-10  1:11   ` David Gibson
2026-08-12 16:36     ` Ammar Yasser
2026-08-02 13:21 ` [RFC v3 4/8] virtio: Define the pasta vhost interface Ammar Yasser
2026-08-10  2:06   ` David Gibson
2026-08-12 17:17     ` Ammar Yasser
2026-08-13  1:16       ` David Gibson
2026-08-02 13:21 ` [RFC v3 5/8] virtio: Implement the pasta vhost functions Ammar Yasser
2026-08-10  6:34   ` David Gibson
2026-08-12 17:57     ` Ammar Yasser
2026-08-13  1:26       ` David Gibson
2026-08-02 13:21 ` [RFC v3 6/8] virtio: Implement pasta vhost acceleration guest->pasta path Ammar Yasser
2026-08-10  7:34   ` David Gibson
2026-08-12 18:17     ` Ammar Yasser
2026-08-13  1:35       ` David Gibson
2026-08-02 13:21 ` [RFC v3 7/8] pasta: Implement pasta vhost TX (pasta->guest) prerequisites Ammar Yasser
2026-08-10  9:01   ` David Gibson
2026-08-12 18:39     ` Ammar Yasser
2026-08-13  2:01       ` David Gibson [this message]
2026-08-02 13:21 ` [RFC v3 8/8] tap: Implement pasta vhost TX Ammar Yasser
2026-08-10  9:18   ` David Gibson
2026-08-12 18:45     ` Ammar Yasser
2026-08-13  2:09       ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=an0liZLGMM50smpg@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=aerosound161@gmail.com \
    --cc=eperezma@redhat.com \
    --cc=passt-dev@passt.top \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).