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
Reviewed-by: David Gibson
@@ -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