public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v5 02/29] iov: Introduce iov_slice(), iov_tail_slice() and iov_tail_drop().
Date: Mon, 26 May 2025 16:19:03 +0200	[thread overview]
Message-ID: <20250526161903.170771ca@elisabeth> (raw)
In-Reply-To: <20250417165136.2688884-3-lvivier@redhat.com>

On Thu, 17 Apr 2025 18:51:09 +0200
Laurent Vivier <lvivier@redhat.com> wrote:

> iov_tail_drop() discards a header from the iov_tail,
> 
> iov_slice() makes a new iov referencing a subset of the data
> in the original iov.
> 
> iov_tail_slice() is a wrapper for iov_slice() using iov_tail
> 
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  iov.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  iov.h |  6 ++++
>  2 files changed, 98 insertions(+)
> 
> diff --git a/iov.c b/iov.c
> index 8c63b7ea6e31..047fcbce7fcd 100644
> --- a/iov.c
> +++ b/iov.c
> @@ -156,6 +156,59 @@ size_t iov_size(const struct iovec *iov, size_t iov_cnt)
>  	return len;
>  }
>  
> +/**
> + * iov_slice -  Make a new iov referencing a subset of the data in the original iov

Nit: iov_slice() - Make ...

> + *
> + * @dst_iov:	 Pointer to the destination array of struct iovec describing
> + *		 the scatter/gather I/O vector to copy to.

From here on, you start mentioning "copy", but, I realised later,
there's no "deep" copy done here. Perhaps a mix of "shallow copy" or
"to duplicate references to [...]" etc. would be less confusing?

> + * @dst_iov_cnt: Maximum number of elements in the destination iov array.
> + * @iov:	 Pointer to the source array of struct iovec describing
> + *		 the scatter/gather I/O vector to copy from.
> + * @iov_cnt:	 Maximum number of elements in the source iov array.
> + * @offset:	 Offset within the source iov from where copying should start.

I would mention explicitly this is only for the first iov, otherwise it
might look like it's a fixed offset that applies to all elements
(...until you find the offset = 0 assignment below), say:

 * @offset:	Offset of the first source iov from where copying should start

> + * @bytes:	 On input, total number of bytes to copy from @iov to @dst_iov,
> + * 		 if @bytes is NULL, copy all the content of @iov,
> + * 		 on output actual number of bytes copied.

It's nice to avoid one additional argument, but to me it looks quite
convoluted, especially as I started reviewing the next patches. What
about:

 * @len:	Maximum byte count of @iov to map onto @dst_iov, 0 means unlimited
 * @copied:	If given, number of bytes referenced by @dst_iov, set on return

> + *
> + * Returns:	 The number of elements successfully copied to the destination
> + *		 iov array, a negative value if there is not enough room in the
> + *		 destination iov array
> + */
> +/* cppcheck-suppress staticFunction */
> +ssize_t iov_slice(struct iovec *dst_iov, size_t dst_iov_cnt,
> +		  const struct iovec *iov, size_t iov_cnt,
> +		  size_t offset, size_t *bytes)
> +{
> +	unsigned int i, j;
> +	size_t remaining = bytes ? *bytes : SIZE_MAX;

Declarations from longest to shortest.

> +
> +	i = iov_skip_bytes(iov, iov_cnt, offset, &offset);
> +
> +	/* create a new iov array referencing a subset of the source one  */

...that's what I would have expected, but actually, the destination iov
is already there. Maybe (also in the function description) use "assign
iov references" rather than "create" or "make a new iov"?

> +	for (j = 0; i < iov_cnt && j < dst_iov_cnt && remaining; i++) {

'j' progresses with 'i'. Strictly speaking, you could use a single
counter, but it might complicate things later. Still, why shouldn't j
be post-decremented together with i, say:

	for (j = 0; i < iov_cnt && j < dst_iov_cnt && remaining; i++, j++) {

?

> +		size_t len = MIN(remaining, iov[i].iov_len - offset);
> +
> +		dst_iov[j].iov_base = (char *)iov[i].iov_base + offset;
> +		dst_iov[j].iov_len = len;
> +		j++;
> +		remaining -= len;
> +		offset = 0;
> +	}
> +	if (j == dst_iov_cnt) {
> +		if (bytes) {
> +			if (remaining)
> +				return -1;
> +		} else if (i != iov_cnt) {
> +			return -1;

...this looks subtle. I'm wondering: what if we skipped enough bytes,
so that i != iov_cnt but we're now referencing everything from dst_iov
as expected? Say that we get as input:

- iov[0]: abcd, iov[1]: efgh
- offset: 4
- dst_iov_cnt: 1
- iov_cnt: 2 (it's iov[0] and iov[1])

now we have:

- iov_dst[0]: efgh
- j == 1
- i == 1, iov_cnt == 2

...but we did "copy" everything, right? Unless I'm missing something,
we should store the result from iov_skip_bytes() (say, 'skipped'), and
then subtract it here.

Actually, the whole "error checking" here looks a bit fragile, and I
wonder if we shouldn't rather always set 'remaining' to the remaining
bytes (even if it's a bit of a waste, when bytes is NULL), then signal
failure whenever remaining != 0.

> +		}
> +	}
> +
> +	if (bytes)
> +		*bytes -= remaining;

So, assuming it's desired (I'm fairly sure it is from the next
patches), 'bytes' is an upper limit, rather than the number of bytes we
_must_ copy (as the current function comment would seem to imply).

If it's not desired, then we should also return error if we "copied"
less than 'bytes'.

> +
> +	return j;
> +}
> +
>  /**
>   * iov_tail_prune() - Remove any unneeded buffers from an IOV tail
>   * @tail:	IO vector tail (modified)
> @@ -191,6 +244,21 @@ size_t iov_tail_size(struct iov_tail *tail)
>  	return iov_size(tail->iov, tail->cnt) - tail->off;
>  }
>  
> +/**
> + * iov_tail_drop() - Discard a header from an IOV tail

Mixing 'header' with 'tail' makes this a bit confusing. Yes, these
vectors are used for headers, but what about calling it simply 'item',
to match the context of this function?

> + * @tail:	IO vector tail
> + * @len:	length to move the head of the tail
> + *
> + * Returns:	true if the tail still contains any bytes, otherwise false
> + */
> +/* cppcheck-suppress unusedFunction */
> +bool iov_tail_drop(struct iov_tail *tail, size_t len)
> +{
> +	tail->off = tail->off + len;
> +
> +	return iov_tail_prune(tail);
> +}
> +
>  /**
>   * iov_peek_header_() - Get pointer to a header from an IOV tail
>   * @tail:	IOV tail to get header from
> @@ -247,3 +315,27 @@ void *iov_remove_header_(struct iov_tail *tail, size_t len, size_t align)
>  	tail->off = tail->off + len;
>  	return p;
>  }
> +
> +/**
> + * iov_tail_slice -  Make a new iov referencing a subset of the data

iov_tail_slice() - ...

Same comment as above: we're just setting references in a passed iov,
not really "making" one.

> + *		     in an iov_tail
> + *
> + * @dst_iov:     Pointer to the destination array of struct iovec describing
> + *		 the scatter/gather I/O vector to copy to.
> + * @dst_iov_cnt: Maximum number of elements in the destination iov array.
> + * @tail:	 Pointer to the source iov_tail
> + * @bytes:	 On input, total number of bytes to copy from @iov to @dst_iov,
> + * 		 if @bytes is NULL, copy all the content of @iov,
> + * 		 on output actual number of bytes copied.
> + *
> + * Returns:      The number of elements successfully copied to the destination
> + *		 iov array, a negative value if there is not enough room in the
> + *		 destination iov array
> + */
> +/* cppcheck-suppress unusedFunction */
> +int iov_tail_slice(struct iovec *dst_iov, size_t dst_iov_cnt,
> +                   struct iov_tail *tail, size_t *bytes)
> +{
> +	return iov_slice(dst_iov, dst_iov_cnt, &tail->iov[0], tail->cnt,
> +			 tail->off, bytes);
> +}
> diff --git a/iov.h b/iov.h
> index 9855bf0c0c32..809f84a2c0a0 100644
> --- a/iov.h
> +++ b/iov.h
> @@ -28,6 +28,9 @@ size_t iov_from_buf(const struct iovec *iov, size_t iov_cnt,
>  size_t iov_to_buf(const struct iovec *iov, size_t iov_cnt,
>                    size_t offset, void *buf, size_t bytes);
>  size_t iov_size(const struct iovec *iov, size_t iov_cnt);
> +ssize_t iov_slice(struct iovec *dst_iov, size_t dst_iov_cnt,
> +		  const struct iovec *iov, size_t iov_cnt,
> +		  size_t offset, size_t *bytes);
>  
>  /*
>   * DOC: Theory of Operation, struct iov_tail
> @@ -72,8 +75,11 @@ struct iov_tail {
>  
>  bool iov_tail_prune(struct iov_tail *tail);
>  size_t iov_tail_size(struct iov_tail *tail);
> +bool iov_tail_drop(struct iov_tail *tail, size_t len);
>  void *iov_peek_header_(struct iov_tail *tail, size_t len, size_t align);
>  void *iov_remove_header_(struct iov_tail *tail, size_t len, size_t align);
> +int iov_tail_slice(struct iovec *dst_iov, size_t dst_iov_cnt,
> +		   struct iov_tail *tail, size_t *bytes);
>  
>  /**
>   * IOV_PEEK_HEADER() - Get typed pointer to a header from an IOV tail

-- 
Stefano


  reply	other threads:[~2025-05-26 14:19 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 16:51 [PATCH v5 00/29] Introduce discontiguous frames management Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 01/29] arp: Don't mix incoming and outgoing buffers Laurent Vivier
2025-05-26 14:18   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 02/29] iov: Introduce iov_slice(), iov_tail_slice() and iov_tail_drop() Laurent Vivier
2025-05-26 14:19   ` Stefano Brivio [this message]
2025-05-26 15:20     ` Laurent Vivier
2025-06-02 13:35       ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 03/29] iov: Update IOV_REMOVE_HEADER() and IOV_PEEK_HEADER() Laurent Vivier
2025-05-26 14:19   ` Stefano Brivio
2025-06-02 15:36     ` Laurent Vivier
2025-06-03  8:42       ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 04/29] tap: Use iov_tail with tap_add_packet() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 05/29] packet: Use iov_tail with packet_add() Laurent Vivier
2025-05-26 14:19   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 06/29] packet: Add packet_data() Laurent Vivier
2025-05-26 14:19   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 07/29] arp: Convert to iov_tail Laurent Vivier
2025-05-26 14:19   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 08/29] ndp: " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 09/29] icmp: " Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 10/29] udp: " Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-05-26 15:47     ` Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 11/29] tcp: Convert tcp_tap_handler() to use iov_tail Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 12/29] tcp: Convert tcp_data_from_tap() " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 13/29] dhcpv6: move offset initialization out of dhcpv6_opt() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 14/29] dhcpv6: Extract sending of NotOnLink status Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 15/29] dhcpv6: Convert to iov_tail Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 16/29] dhcpv6: Use iov_tail in dhcpv6_opt() Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 17/29] dhcp: Convert to iov_tail Laurent Vivier
2025-05-26 14:20   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 18/29] ip: Use iov_tail in ipv6_l4hdr() Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 19/29] tap: Convert tap4_handler() to iov_tail Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 20/29] tap: Convert tap6_handler() " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 21/29] arp: use iov_tail rather than pool Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 22/29] dhcp: " Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 23/29] dhcpv6: " Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 24/29] icmp: " Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 25/29] ndp: " Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 26/29] packet: remove PACKET_POOL() and PACKET_POOL_P() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 27/29] packet: remove unused parameter from PACKET_POOL_DECL() Laurent Vivier
2025-04-17 16:51 ` [PATCH v5 28/29] packet: add memory regions information into pool Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-04-17 16:51 ` [PATCH v5 29/29] packet: use buf to store iovec array Laurent Vivier
2025-05-26 14:21   ` Stefano Brivio
2025-05-27 13:16     ` Laurent Vivier
2025-06-02 13:35       ` Stefano Brivio

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=20250526161903.170771ca@elisabeth \
    --to=sbrivio@redhat.com \
    --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).