[PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap()
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
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
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
On Fri, 12 Dec 2025 13:30:32 +1100
David Gibson
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
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.
Assuming we're not trying to abandon that convention: why can't "tap" be "anything that's not vhost-user"? We could document that at the top of tap.c and it would still be clearer than the current situation. It would be still somewhat confusing that a big part of the code in tap.c is also relevant for vhost-user, but in a number of places, there, we call the vhost-user specific implementation and return early. I got to dislike "buf" over timing because it's more typing and doesn't mean much other than "non-vhost-user" (vhost-user uses buffers too). Maybe we could live happier by letting "tap" be that magic word? -- Stefano
participants (3)
-
David Gibson
-
Laurent Vivier
-
Stefano Brivio