From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ffu5u5ES; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 2A0755A0262 for ; Tue, 17 Mar 2026 16:23:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773761036; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A8cjHTLji+V0snK8RlPfeYfEWpU/t/btrEEt/LfkM00=; b=ffu5u5ESZsI8XSE7SOVy+zEgoawaJHLjGh6gpV30ke4+xTkt3Skh47afA823ND/LB97XUJ XZs6LVEtkVJy5pdHiUhHp/8TX7o5gkv659kOuPYoe+cvf1ptDLDoLPDYSLQbadeWtJZrU3 iwf/Qp+RORt3ezV3KUdw0VABckMskEY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-125-X-8ED21-MhmoRdqqDHFi5g-1; Tue, 17 Mar 2026 11:23:54 -0400 X-MC-Unique: X-8ED21-MhmoRdqqDHFi5g-1 X-Mimecast-MFC-AGG-ID: X-8ED21-MhmoRdqqDHFi5g_1773761033 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-439cbfcfc21so5646954f8f.2 for ; Tue, 17 Mar 2026 08:23:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773761033; x=1774365833; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A8cjHTLji+V0snK8RlPfeYfEWpU/t/btrEEt/LfkM00=; b=hyCCU2EaWde9UDD/fGrb3oDNWSCL2wujGiUBcS/bWw6uFArFsO8/mxA3ALh3iGxnd7 omCaUhY6oUPnib6tju3RDYLIl6PfHy4AKxzwdKyqoU1AmHwtTTdskKARM3X7kENQKPUT MFyF36Gbu0QaTDPVeXW2YrfERH5p7J3IjthwaXFKOb2xaOAJIHfYpneaBsUi6MdsZQMi Pb/rByBWQANh7KYpmh6jJUrlM+r4jVehaD1Ingzn3RnDDNrdoM6p1Nvx9Y1k19nb6JuJ RHr5ZKaxvVtmb3aV5A68WnrkwXs16usvm76ezbL6ZNIGgm4iE94KLadkpdI5CHcdzsJJ CJRw== X-Forwarded-Encrypted: i=1; AJvYcCUBC12HvBtu3mS2nMfbM7fwiJDHT/WuoDVWl8aQ3V2XC8ljLomc5HaPVdis/7aDMfMlL77C3rLPkbg=@passt.top X-Gm-Message-State: AOJu0Yx4zgBcqR4ZbBxM241dRby/tBtfL5XIjiCPI1sziwN7Od7hZKLg 5mLHMskkPgYuXhlvjt+DHK44S9rewMlP+Q5ZK0TLh7MTisO+MEhTVsdprd5q/h75YZ0i26t8VfA 7M8nK367hxZd7Q2juK9aYxbHuk5WS03691pb4BsVcb/hwC1c2BEaxvw== X-Gm-Gg: ATEYQzyPtrvt4knlvRGKY2E/YDB7z2OLp2lyMLLhgX1dGAhQPmkJiLByF0ySez+e4LI R4EAdhYkmUrkL7yzp7yyQoXDgZSNR7wlBhmcF2VnRAiJN3bPS+V+2tyPp5gGAZPx0ZLfADpo1j8 h52CeDbDCLHvCrEJrm7zDMn0t4pGut2gcQp8XF7biw4O+zvNcXUi8BfGvlZs47xdgulZEocN1Xq Ch9M/Lu1UMxVRcuBYj8rXoQLHMc+xLB9bw3PGOiHuXsqlmTAko6jgCqPoVaFxgCf95QrPv87K+I ARCe1mzhPYJcS9dUfB9wfy5Aw8hBPhI79Sqwv7EEcUWLRcR+1UGlOZ2yRiKs1T9PhCHxQCwFAYr 4Q5kW1JThJCOCaZTYtmKMx4qsVBy0RlQScBQ/g6GISC7wMjoQ3A== X-Received: by 2002:a5d:5f53:0:b0:439:bd26:3c63 with SMTP id ffacd0b85a97d-43a04db4bf4mr30284472f8f.28.1773761032809; Tue, 17 Mar 2026 08:23:52 -0700 (PDT) X-Received: by 2002:a5d:5f53:0:b0:439:bd26:3c63 with SMTP id ffacd0b85a97d-43a04db4bf4mr30284417f8f.28.1773761032202; Tue, 17 Mar 2026 08:23:52 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518a3e3csm137895f8f.35.2026.03.17.08.23.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 08:23:51 -0700 (PDT) From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v2 3/3] vu_common: Move iovec management into vu_collect() Message-ID: <20260317162350.058e10e0@elisabeth> In-Reply-To: References: <20260313182618.4157365-1-lvivier@redhat.com> <20260313182618.4157365-4-lvivier@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Tue, 17 Mar 2026 16:23:51 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: FQPDFsW0g11tvjqcVKvJTZBDpj_DiQTu08NtSbaK570_1773761033 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FICD5QWCHKBSJLKOEZP7RWWTEB6XO5QI X-Message-ID-Hash: FICD5QWCHKBSJLKOEZP7RWWTEB6XO5QI X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Gibson , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, 17 Mar 2026 08:25:49 +0100 Laurent Vivier wrote: > On 3/17/26 03:40, David Gibson wrote: > > On Fri, Mar 13, 2026 at 07:26:18PM +0100, Laurent Vivier wrote: > >> Previously, callers had to pre-initialize virtqueue elements with iovec > >> entries using vu_set_element() or vu_init_elem() before calling > >> vu_collect(). This meant each element owned a fixed, pre-assigned iovec > >> slot. > >> > >> Move the iovec array into vu_collect() as explicit parameters (in_sg, > >> max_in_sg, and in_num), letting it pass the remaining iovec capacity > >> directly to vu_queue_pop(). A running current_iov counter tracks > >> consumed entries across elements, so multiple elements share a single > >> iovec pool. The optional in_num output parameter reports how many iovec > >> entries were consumed, allowing callers to track usage across multiple > >> vu_collect() calls. > >> > >> This removes vu_set_element() and vu_init_elem() which are no longer > >> needed, and is a prerequisite for multi-buffer support where a single > >> virtqueue element can use more than one iovec entry. For now, callers > >> assert the current single-iovec-per-element invariant until they are > >> updated to handle multiple iovecs. > >> > >> Signed-off-by: Laurent Vivier > > > > Reviewed-by: David Gibson > > > > Couple of thoughts on possible polish below. > > > > [snip] > >> /** > >> * vu_collect() - collect virtio buffers from a given virtqueue > >> * @vdev: vhost-user device > >> * @vq: virtqueue to collect from > >> - * @elem: Array of virtqueue element > >> - * each element must be initialized with one iovec entry > >> - * in the in_sg array. > >> + * @elem: Array of @max_elem virtqueue elements > >> * @max_elem: Number of virtqueue elements in the array > >> + * @in_sg: Incoming iovec array for device-writable descriptors > >> + * @max_in_sg: Maximum number of entries in @in_sg > >> + * @in_num: Number of collected entries from @in_sg (output) > >> * @size: Maximum size of the data in the frame > >> * @collected: Collected buffer length, up to @size, set on return > >> * > >> @@ -80,20 +67,21 @@ void vu_init_elem(struct vu_virtq_element *elem, struct iovec *iov, int elem_cnt > >> */ > >> int vu_collect(const struct vu_dev *vdev, struct vu_virtq *vq, > >> struct vu_virtq_element *elem, int max_elem, > >> + struct iovec *in_sg, size_t max_in_sg, size_t *in_num, > >> size_t size, size_t *collected) > >> { > >> size_t current_size = 0; > >> + size_t current_iov = 0; > >> int elem_cnt = 0; > >> > >> - while (current_size < size && elem_cnt < max_elem) { > >> - struct iovec *iov; > >> + while (current_size < size && elem_cnt < max_elem && > >> + current_iov < max_in_sg) { > >> int ret; > >> > >> ret = vu_queue_pop(vdev, vq, &elem[elem_cnt], > >> - elem[elem_cnt].in_sg, > >> - elem[elem_cnt].in_num, > >> - elem[elem_cnt].out_sg, > >> - elem[elem_cnt].out_num); > >> + &in_sg[current_iov], > >> + max_in_sg - current_iov, > >> + NULL, 0); > >> if (ret < 0) > >> break; > >> > >> @@ -103,18 +91,22 @@ int vu_collect(const struct vu_dev *vdev, struct vu_virtq *vq, > >> break; > >> } > >> > >> - iov = &elem[elem_cnt].in_sg[0]; > >> - > >> - if (iov->iov_len > size - current_size) > >> - iov->iov_len = size - current_size; > >> + elem[elem_cnt].in_num = iov_truncate(elem[elem_cnt].in_sg, > >> + elem[elem_cnt].in_num, > >> + size - current_size); > > > > Will elem[].in_num always end up with the same value as the @in_num > > parameter? If so, do we need the explicit parameter? > > @in_num parameter of vu_collect()? > > @in_num is the sum of all elem[].in_num, it can be computed by the caller function from > elem, but it is simpler to return it as we need to compute it in the loop. I'm not sure I understood the point of David's comment here, and this explanation makes sense to me now, but it took me a bit to figure that out. Could it be that @in_num is a bit confusing as it has "in" and "num" in it, but it's actually an output representing how many "in" entries we used/need? What if we rename it to @in_used or @in_collected? -- Stefano