From: David Gibson <david@gibson.dropbear.id.au>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top
Subject: Re: [PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap()
Date: Fri, 12 Dec 2025 13:30:32 +1100 [thread overview]
Message-ID: <aTt-SCQqRJPjWNw9@zatzit> (raw)
In-Reply-To: <20251211141626.301969-1-lvivier@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4605 bytes --]
On Thu, Dec 11, 2025 at 03:16:26PM +0100, Laurent Vivier wrote:
> The function udp_vu_sock_to_tap() sends data to the vhost-user interface,
> not the tap interface. Rename it to udp_sock_to_vu() to accurately reflect
> its destination.
>
> The function udp_buf_sock_to_tap() includes a "buf_" prefix that is now
> redundant. Since the functions can be distinguished by their destination
> (to_tap vs. to_vu), drop the prefix and rename it to udp_sock_to_tap().
>
> No functional change.
>
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Eh, I mean using "tap" to mean the guest side interface, even if it's
not based on /dev/net/tap is pretty well established at this point.
I do think udp_sock_to_vu() is a better name regardless. I'm a bit
less convinced on renaming udp_buf_sock_to_tap(). If we're trying to
abandon the "tap means any guest interface" convention, then
udp_sock_to_tap() is still inaccurate, since it can also send to a
qemu socket. If we're not trying to abandon that convention then it
suggests that the function does any forwarding to the guest, not just
the non-vu case.
> ---
> udp.c | 15 +++++++--------
> udp_vu.c | 4 ++--
> udp_vu.h | 2 +-
> 3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/udp.c b/udp.c
> index 08bec50a27af..10704681973b 100644
> --- a/udp.c
> +++ b/udp.c
> @@ -824,14 +824,14 @@ static void udp_sock_to_sock(const struct ctx *c, int from_s, int n,
> }
>
> /**
> - * udp_buf_sock_to_tap() - Forward datagrams from socket to tap
> + * udp_sock_to_tap() - Forward datagrams from socket to tap
> * @c: Execution context
> * @s: Socket to read data from
> * @n: Maximum number of datagrams to forward
> * @tosidx: Flow & side to forward data from @s to
> */
> -static void udp_buf_sock_to_tap(const struct ctx *c, int s, int n,
> - flow_sidx_t tosidx)
> +static void udp_sock_to_tap(const struct ctx *c, int s, int n,
> + flow_sidx_t tosidx)
> {
> const struct flowside *toside = flowside_at_sidx(tosidx);
> struct udp_flow *uflow = udp_at_sidx(tosidx);
> @@ -892,9 +892,9 @@ void udp_sock_fwd(const struct ctx *c, int s, uint8_t frompif,
> udp_sock_to_sock(c, s, 1, tosidx);
> } else if (topif == PIF_TAP) {
> if (c->mode == MODE_VU)
> - udp_vu_sock_to_tap(c, s, 1, tosidx);
> + udp_sock_to_vu(c, s, 1, tosidx);
> else
> - udp_buf_sock_to_tap(c, s, 1, tosidx);
> + udp_sock_to_tap(c, s, 1, tosidx);
> } else if (flow_sidx_valid(tosidx)) {
> struct udp_flow *uflow = udp_at_sidx(tosidx);
>
> @@ -972,10 +972,9 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref,
> udp_sock_to_sock(c, ref.fd, n, tosidx);
> } else if (topif == PIF_TAP) {
> if (c->mode == MODE_VU) {
> - udp_vu_sock_to_tap(c, s, UDP_MAX_FRAMES,
> - tosidx);
> + udp_sock_to_vu(c, s, UDP_MAX_FRAMES, tosidx);
> } else {
> - udp_buf_sock_to_tap(c, s, n, tosidx);
> + udp_sock_to_tap(c, s, n, tosidx);
> }
> } else {
> flow_err(uflow,
> diff --git a/udp_vu.c b/udp_vu.c
> index c30dcf97698f..f7ed6bc6a67c 100644
> --- a/udp_vu.c
> +++ b/udp_vu.c
> @@ -197,13 +197,13 @@ static void udp_vu_csum(const struct flowside *toside, int iov_used)
> }
>
> /**
> - * udp_vu_sock_to_tap() - Forward datagrams from socket to tap
> + * udp_sock_to_vu() - Forward datagrams from socket to vhost-user
> * @c: Execution context
> * @s: Socket to read data from
> * @n: Maximum number of datagrams to forward
> * @tosidx: Flow & side to forward data from @s to
> */
> -void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx)
> +void udp_sock_to_vu(const struct ctx *c, int s, int n, flow_sidx_t tosidx)
> {
> const struct flowside *toside = flowside_at_sidx(tosidx);
> bool v6 = !(inany_v4(&toside->eaddr) && inany_v4(&toside->oaddr));
> diff --git a/udp_vu.h b/udp_vu.h
> index 576b0e716f3d..669bde1c10dc 100644
> --- a/udp_vu.h
> +++ b/udp_vu.h
> @@ -8,6 +8,6 @@
>
> void udp_vu_listen_sock_data(const struct ctx *c, union epoll_ref ref,
> const struct timespec *now);
> -void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx);
> +void udp_sock_to_vu(const struct ctx *c, int s, int n, flow_sidx_t tosidx);
>
> #endif /* UDP_VU_H */
> --
> 2.51.1
>
--
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 --]
prev parent reply other threads:[~2025-12-12 2:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 14:16 Laurent Vivier
2025-12-12 2:30 ` 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=aTt-SCQqRJPjWNw9@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).