public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v8 30/30] packet: Add support for multi-vector packets
Date: Thu, 7 Aug 2025 16:17:33 +1000	[thread overview]
Message-ID: <aJRE_cdkV7sNt3OZ@zatzit> (raw)
In-Reply-To: <20250805154628.301343-31-lvivier@redhat.com>

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

On Tue, Aug 05, 2025 at 05:46:28PM +0200, Laurent Vivier wrote:
> The packet pool was previously limited to handling packets contained
> within a single buffer.
> 
> This patch extends the packet pool to support iovec array,
> allowing a single logical packet to be composed of multiple iovec.
> 
> To accommodate this, the storage format within the pool is modified.
> For a multi-vector packet, a header entry is now stored first with
> iov_base = NULL and iov_len holding the number of subsequent
> vectors. The actual data vectors are then stored in the following
> pool slots.
> 
> The packet_add_do() and packet_get_do() functions are updated to
> manage this new format for storing and retrieving packets. The
> pool_full() check is also adjusted to ensure there is enough
> space for all vectors of a new packet before adding it.
> 
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  packet.c | 50 +++++++++++++++++++++++++++++++++-----------------
>  packet.h |  2 +-
>  tap.c    |  4 ++--
>  3 files changed, 36 insertions(+), 20 deletions(-)
> 
> diff --git a/packet.c b/packet.c
> index 4b93688509a4..d697232d951a 100644
> --- a/packet.c
> +++ b/packet.c
> @@ -90,12 +90,13 @@ static int packet_check_range(const struct pool *p, const char *ptr, size_t len,
>  /**
>   * pool_full() - Is a packet pool full?
>   * @p:		Pointer to packet pool
> + * @data:	check data can fit in the pool
>   *
> - * Return: true if the pool is full, false if more packets can be added
> + * Return: true if the pool is full, false if data can be added
>   */
> -bool pool_full(const struct pool *p)
> +bool pool_full(const struct pool *p, const struct iov_tail *data)

Given the slightly changed semantics, I wonder if 'pool_can_fit()'
might be a better name now.

>  {
> -	return p->count >= p->size;
> +	return p->count + data->cnt  + (data->cnt > 1) >= p->size;

This test is only correct if data is already pruned.  As I've said
elsewhere, it might be worth changing to the assumption that iov_tails
are pruned everywhere outside the iov_tail internal handling.

Oh.. also I think the new check is off by one (in the relatively safe
direction).  It will say there's no room when there is just exactly
enough room.

>  }
>  
>  /**
> @@ -108,11 +109,9 @@ bool pool_full(const struct pool *p)
>  void packet_add_do(struct pool *p, struct iov_tail *data,
>  		   const char *func, int line)
>  {
> -	size_t idx = p->count;
> -	const char *start;
> -	size_t len;
> +	size_t idx = p->count, i, offset;
>  
> -	if (pool_full(p)) {
> +	if (pool_full(p, data)) {
>  		debug("add packet index %zu to pool with size %zu, %s:%i",
>  		      idx, p->size, func, line);
>  		return;
> @@ -121,18 +120,30 @@ void packet_add_do(struct pool *p, struct iov_tail *data,
>  	if (!iov_tail_prune(data))
>  		return;
>  
> -	ASSERT(data->cnt == 1); /* we don't support iovec */
> +	if (data->cnt > 1) {
> +		p->pkt[idx].iov_base = NULL;
> +		p->pkt[idx].iov_len = data->cnt;
> +		idx++;
> +	}
>  
> -	len = data->iov[0].iov_len - data->off;
> -	start = (char *)data->iov[0].iov_base + data->off;
> +	offset = data->off;
> +	for (i = 0; i < data->cnt; i++) {
> +		const char *start;
> +		size_t len;
>  
> -	if (packet_check_range(p, start, len, func, line))
> -		return;
> +		len = data->iov[i].iov_len - offset;
> +		start = (char *)data->iov[i].iov_base + offset;
> +		offset = 0;
>  
> -	p->pkt[idx].iov_base = (void *)start;
> -	p->pkt[idx].iov_len = len;
> +		if (packet_check_range(p, start, len, func, line))
> +			return;
>  
> -	p->count++;
> +		p->pkt[idx].iov_base = (void *)start;
> +		p->pkt[idx].iov_len = len;
> +		idx++;

Hm. Isn't the above equivalent to iov_tail_clone()?  Is calling
packet_check_range() on each chunk the only reason for open-coding it
here?

> +	}
> +
> +	p->count = idx;
>  }
>  
>  /**
> @@ -162,9 +173,14 @@ bool packet_get_do(const struct pool *p, size_t idx,
>  		return false;
>  	}
>  
> -	data->cnt = 1;
> +	if (p->pkt[idx].iov_base) {
> +		data->cnt = 1;
> +		data->iov = &p->pkt[idx];
> +	} else {
> +		data->cnt = p->pkt[idx].iov_len;
> +		data->iov = &p->pkt[idx + 1];
> +	}
>  	data->off = 0;
> -	data->iov = &p->pkt[idx];
>  
>  	for (i = 0; i < data->cnt; i++) {
>  		ASSERT_WITH_MSG(!packet_check_range(p, data->iov[i].iov_base,
> diff --git a/packet.h b/packet.h
> index e51cbd19fdc4..67dc7deb17db 100644
> --- a/packet.h
> +++ b/packet.h
> @@ -37,7 +37,7 @@ void packet_add_do(struct pool *p, struct iov_tail *data,
>  		   const char *func, int line);
>  bool packet_get_do(const struct pool *p, const size_t idx,
>  		   struct iov_tail *data, const char *func, int line);
> -bool pool_full(const struct pool *p);
> +bool pool_full(const struct pool *p, const struct iov_tail *data);
>  void pool_flush(struct pool *p);
>  
>  #define packet_add(p, data)					\
> diff --git a/tap.c b/tap.c
> index 9fd00915bb01..95688b22fcb7 100644
> --- a/tap.c
> +++ b/tap.c
> @@ -1103,14 +1103,14 @@ void tap_add_packet(struct ctx *c, struct iov_tail *data,
>  	switch (ntohs(eh->h_proto)) {
>  	case ETH_P_ARP:
>  	case ETH_P_IP:
> -		if (pool_full(pool_tap4)) {
> +		if (pool_full(pool_tap4, data)) {
>  			tap4_handler(c, pool_tap4, now);
>  			pool_flush(pool_tap4);
>  		}
>  		packet_add(pool_tap4, data);
>  		break;
>  	case ETH_P_IPV6:
> -		if (pool_full(pool_tap6)) {
> +		if (pool_full(pool_tap6, data)) {
>  			tap6_handler(c, pool_tap6, now);
>  			pool_flush(pool_tap6);
>  		}

-- 
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:[~2025-08-07  6:18 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-05 15:45 [PATCH v8 00/30] Introduce discontiguous frames management Laurent Vivier
2025-08-05 15:45 ` [PATCH v8 01/30] arp: Don't mix incoming and outgoing buffers Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 02/30] iov: Introduce iov_tail_clone() and iov_tail_drop() Laurent Vivier
2025-08-06  1:32   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 03/30] iov: Update IOV_REMOVE_HEADER() and IOV_PEEK_HEADER() Laurent Vivier
2025-08-06  1:45   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 04/30] tap: Use iov_tail with tap_add_packet() Laurent Vivier
2025-08-06  1:56   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 05/30] packet: Use iov_tail with packet_add() Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 06/30] packet: Add packet_data() Laurent Vivier
2025-08-06  2:14   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 07/30] arp: Convert to iov_tail Laurent Vivier
2025-08-06  2:17   ` David Gibson
2025-08-07 12:58     ` Laurent Vivier
2025-08-07 13:11       ` Stefano Brivio
2025-08-13  2:21         ` David Gibson
2025-08-05 15:46 ` [PATCH v8 08/30] ndp: " Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 09/30] icmp: " Laurent Vivier
2025-08-06  2:20   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 10/30] udp: " Laurent Vivier
2025-08-06  2:23   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 11/30] tcp: Convert tcp_tap_handler() to use iov_tail Laurent Vivier
2025-08-06  2:35   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 12/30] tcp: Convert tcp_data_from_tap() " Laurent Vivier
2025-08-06  2:37   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 13/30] dhcpv6: move offset initialization out of dhcpv6_opt() Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 14/30] dhcpv6: Extract sending of NotOnLink status Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 15/30] dhcpv6: Convert to iov_tail Laurent Vivier
2025-08-05 15:46 ` [PATCH v8 16/30] dhcpv6: Use iov_tail in dhcpv6_opt() Laurent Vivier
2025-08-06  4:14   ` David Gibson
2025-08-08 13:59     ` Laurent Vivier
2025-08-13  2:29       ` David Gibson
2025-08-05 15:46 ` [PATCH v8 17/30] dhcp: Convert to iov_tail Laurent Vivier
2025-08-06  4:38   ` David Gibson
2025-08-08  9:33     ` Laurent Vivier
2025-08-13  2:27       ` David Gibson
2025-08-05 15:46 ` [PATCH v8 18/30] ip: Use iov_tail in ipv6_l4hdr() Laurent Vivier
2025-08-06  5:12   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 19/30] tap: Convert tap4_handler() to iov_tail Laurent Vivier
2025-08-06  5:17   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 20/30] tap: Convert tap6_handler() " Laurent Vivier
2025-08-06  6:21   ` David Gibson
2025-08-08 13:57     ` Laurent Vivier
2025-08-13  3:22       ` David Gibson
2025-08-05 15:46 ` [PATCH v8 21/30] packet: rename packet_data() to packet_get() Laurent Vivier
2025-08-06  6:22   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 22/30] arp: use iov_tail rather than pool Laurent Vivier
2025-08-06  6:24   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 23/30] dhcp: " Laurent Vivier
2025-08-06  6:26   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 24/30] dhcpv6: " Laurent Vivier
2025-08-06  6:27   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 25/30] icmp: " Laurent Vivier
2025-08-06  6:29   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 26/30] ndp: " Laurent Vivier
2025-08-06  6:31   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 27/30] packet: remove PACKET_POOL() and PACKET_POOL_P() Laurent Vivier
2025-08-06  6:32   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 28/30] packet: remove unused parameter from PACKET_POOL_DECL() Laurent Vivier
2025-08-06  6:33   ` David Gibson
2025-08-05 15:46 ` [PATCH v8 29/30] packet: Refactor vhost-user memory region handling Laurent Vivier
2025-08-07  6:10   ` David Gibson
2025-08-07  9:05     ` Laurent Vivier
2025-08-07 11:44       ` David Gibson
2025-08-05 15:46 ` [PATCH v8 30/30] packet: Add support for multi-vector packets Laurent Vivier
2025-08-07  6:17   ` David Gibson [this message]

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=aJRE_cdkV7sNt3OZ@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=lvivier@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).