On Fri, Jul 31, 2026 at 06:16:11PM +0200, Laurent Vivier wrote:
> Thread a qpair parameter from the entry points (tcp_sock_handler,
> tcp_timer_handler, tcp_tap_handler, tcp_defer_handler) through every
> intermediate function down to the vhost-user send functions, so callers
> explicitly select the target RX virtqueue instead of hardcoding
> QPAIR_DEFAULT.
> 
> Add a qpair parameter to tcp_send_flag(), tcp_data_from_sock(),
> tcp_rst_do() and its tcp_rst() macro, tcp_rewind_seq(),
> tcp_data_from_tap(), tcp_conn_from_sock_finish(), tcp_connect_finish(),
> tcp_tap_window_update(), tcp_conn_from_tap(), tcp_rst_no_conn(),
> tcp_keepalive(), and tcp_inactivity().
> 
> tcp_vu_send_flag() and tcp_vu_data_from_sock() now use the passed
> qpair to select the RX virtqueue instead of always using
> QPAIR_DEFAULT.
> 
> The buffer-based path (tcp_buf.c) does not thread qpair since it is
> only used in non-vhost-user mode.
> 
> No functional change.
> 
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

.. with one minor concern about comment clarity:

[snip]
> @@ -1862,13 +1869,14 @@ static int tcp_sock_consume(const struct tcp_tap_conn *conn, uint32_t ack_seq)
>   * @c:		Execution context
>   * @conn:	Connection pointer
>   * @now:	Current timestamp
> + * @qpair:	Queue pair to process

IIUC, for tcp_data_from_sock() and other socket initiated entry
points, the qpair number will eventually be derived from which epoll
set the event arrived on, yes?  I'm not sure "Queue pair to process"
really conveys that.

-- 
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