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=Kt9AJkLN; 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 923B25A0262 for ; Tue, 17 Mar 2026 17:35:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773765343; 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=3zljJd2tNnKvzv4L9wcjwgmyF2GT1g9Gb8tBypE60aA=; b=Kt9AJkLNN0m6J1GCLJwyTNz0RBm0AdQDyD87ZpO3k/GUbzMfw7e5bd8fShzC9+Z/ChbBwk 1PsqbTe3nZvUTZ8cS1n01gQ8EYMM0OLlL5fAhX4wdkKMBWlRIv8NbGaG78Ol/GMjWHvlTo SEcLbYBePcbTndu5v1L5ztc0IMFjcZE= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-287-m2B9ZMWZNaaL9sglVnI51g-1; Tue, 17 Mar 2026 12:35:42 -0400 X-MC-Unique: m2B9ZMWZNaaL9sglVnI51g-1 X-Mimecast-MFC-AGG-ID: m2B9ZMWZNaaL9sglVnI51g_1773765341 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43b3a0d25d8so2067698f8f.3 for ; Tue, 17 Mar 2026 09:35:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773765341; x=1774370141; 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=Oi1foMjqvPOEJ7s0Yq3tFFpLiEITmh4ZkbNiTxvZkjs=; b=de0ifghsZO1ivBCvtEeYqfrDe7xa+M5wlWpz0WnQJ49FIO4v5RfOKRzwd4Eq08S68n gN/Zc3aX9z8S1IwQK2Tftx8ZZrZ1QVCqgTouj7Cp93Pa1Mg80PP2DS2PRJjDzCp6UKki +8scJC9UyyXd1OIoTsfq6SyU8q1RAucEYC2KSe5uhM9GlwnX4+eUKk5iTUyGIqiqYIKo KBexX0bP7K1FRen8f2ZvMJYO1CprGS2bBzdf7/M9C7S5FqboPadPI9AsENXki11HKlpO 15CLA7Hvtj5BWtmezRrHRcWAmfH/5Bn8vIFuWhLTQchT4VGyBwUHutfQiBU7wBNJCdJz luwA== X-Forwarded-Encrypted: i=1; AJvYcCWKyUauWGUPo4cKQxPvJsesp+HzBHzO3u9przZTXFibsu3hjk6Q2o1/T5KN1yFCdXMfg9Q6YnBky0A=@passt.top X-Gm-Message-State: AOJu0YzLvREODWxkhc61rO/2I3F0t2r38HYNRwh3luPzCVomQvwR0a5k wgqPL4BJS19qyhOc8c0X+c0Pehc3P3qp0HTmdTYU1wFYrBfQFxSGTWt7dBYrTGPaa66HogsCciU 04yQA9Mt4DCLpr2VwU8r5mNC7bP88zCnZeyVWzD/nMxRX3d4r7L/s1Q== X-Gm-Gg: ATEYQzxvbmiL1Vl//1tGWyfpoRB7NeJYb4VHCg640kpXFlz+aO4Q4V+5Gs57ZmOKswl QHU+Gw/I2hwsuVmcyflhKbYjTHMOLaWC/CwG9SVj/ltHyxl47ERtwCOQGoAbh/BAaLIr+ljuhAX pmqBZ0x1MXfIjvM+Kx3SzUYKIdlbiAoy58eMAoVvBjSS3VY5Az+rI8vfonzLfZ/kJseqEiMSpYr YohV0BiHYtdjlEcHcM1VKFMii/KdVInNZoTt5SYR5UheJG2TJMvaLyTqySwuLXjVZfE8V7xf0qb Ta/GpP4eOqQncODIKvl0kQUhXIH/WGMvL35WzuDAiZbE9u9c9xTKRkXzKf2k9a030pmcPYfI3E7 sBG4+r8GqHEqgmGbn7AX5ufqB4uYBDB5e X-Received: by 2002:a05:6000:25c6:b0:43b:492c:8345 with SMTP id ffacd0b85a97d-43b492c863bmr8308525f8f.10.1773765340723; Tue, 17 Mar 2026 09:35:40 -0700 (PDT) X-Received: by 2002:a05:6000:25c6:b0:43b:492c:8345 with SMTP id ffacd0b85a97d-43b492c863bmr8308449f8f.10.1773765340081; Tue, 17 Mar 2026 09:35:40 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b518a3dfasm489519f8f.33.2026.03.17.09.35.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 09:35:39 -0700 (PDT) From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v2 3/3] vu_common: Move iovec management into vu_collect() Message-ID: <20260317173538.7938b2a2@elisabeth> In-Reply-To: <4705f7ab-9277-4462-ada6-6bee39342627@redhat.com> References: <20260313182618.4157365-1-lvivier@redhat.com> <20260313182618.4157365-4-lvivier@redhat.com> <20260317162350.058e10e0@elisabeth> <4705f7ab-9277-4462-ada6-6bee39342627@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 17:35:39 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: maeZH6UF4uF79jDikfdQfodZ9fkkohxjpjUkKEXpmqM_1773765341 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: NW76S7L64K7Q5NWRNDNAI3NUVJV6UK4Y X-Message-ID-Hash: NW76S7L64K7Q5NWRNDNAI3NUVJV6UK4Y 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 17:30:32 +0100 Laurent Vivier wrote: > On 3/17/26 16:23, Stefano Brivio wrote: > > On Tue, 17 Mar 2026 08:25:49 +0100 > > Laurent Vivier wrote: > > =20 > >> On 3/17/26 03:40, David Gibson wrote: =20 > >>> On Fri, Mar 13, 2026 at 07:26:18PM +0100, Laurent Vivier wrote: =20 > >>>> Previously, callers had to pre-initialize virtqueue elements with io= vec > >>>> entries using vu_set_element() or vu_init_elem() before calling > >>>> vu_collect(). This meant each element owned a fixed, pre-assigned i= ovec > >>>> 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 singl= e > >>>> iovec pool. The optional in_num output parameter reports how many i= ovec > >>>> entries were consumed, allowing callers to track usage across multip= le > >>>> 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 singl= e > >>>> virtqueue element can use more than one iovec entry. For now, calle= rs > >>>> assert the current single-iovec-per-element invariant until they are > >>>> updated to handle multiple iovecs. > >>>> > >>>> Signed-off-by: Laurent Vivier =20 > >>> > >>> Reviewed-by: David Gibson > >>> > >>> Couple of thoughts on possible polish below. > >>> > >>> [snip] =20 > >>>> /** > >>>> * vu_collect() - collect virtio buffers from a given virtqueue > >>>> * @vdev:=09=09vhost-user device > >>>> * @vq:=09=09=09virtqueue to collect from > >>>> - * @elem:=09=09Array of virtqueue element > >>>> - * =09=09=09each element must be initialized with one iovec entry > >>>> - * =09=09=09in the in_sg array. > >>>> + * @elem:=09=09Array of @max_elem virtqueue elements > >>>> * @max_elem:=09=09Number of virtqueue elements in the array > >>>> + * @in_sg:=09=09Incoming iovec array for device-writable descriptor= s > >>>> + * @max_in_sg:=09=09Maximum number of entries in @in_sg > >>>> + * @in_num:=09=09Number of collected entries from @in_sg (output) > >>>> * @size:=09=09Maximum size of the data in the frame > >>>> * @collected:=09=09Collected 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, > >>>> =09 struct vu_virtq_element *elem, int max_elem, > >>>> +=09 struct iovec *in_sg, size_t max_in_sg, size_t *in_num, > >>>> =09 size_t size, size_t *collected) > >>>> { > >>>> =09size_t current_size =3D 0; > >>>> +=09size_t current_iov =3D 0; > >>>> =09int elem_cnt =3D 0; > >>>> =20 > >>>> -=09while (current_size < size && elem_cnt < max_elem) { > >>>> -=09=09struct iovec *iov; > >>>> +=09while (current_size < size && elem_cnt < max_elem && > >>>> +=09 current_iov < max_in_sg) { > >>>> =09=09int ret; > >>>> =20 > >>>> =09=09ret =3D vu_queue_pop(vdev, vq, &elem[elem_cnt], > >>>> -=09=09=09=09 elem[elem_cnt].in_sg, > >>>> -=09=09=09=09 elem[elem_cnt].in_num, > >>>> -=09=09=09=09 elem[elem_cnt].out_sg, > >>>> -=09=09=09=09 elem[elem_cnt].out_num); > >>>> +=09=09=09=09 &in_sg[current_iov], > >>>> +=09=09=09=09 max_in_sg - current_iov, > >>>> +=09=09=09=09 NULL, 0); > >>>> =09=09if (ret < 0) > >>>> =09=09=09break; > >>>> =20 > >>>> @@ -103,18 +91,22 @@ int vu_collect(const struct vu_dev *vdev, struc= t vu_virtq *vq, > >>>> =09=09=09break; > >>>> =09=09} > >>>> =20 > >>>> -=09=09iov =3D &elem[elem_cnt].in_sg[0]; > >>>> - > >>>> -=09=09if (iov->iov_len > size - current_size) > >>>> -=09=09=09iov->iov_len =3D size - current_size; > >>>> +=09=09elem[elem_cnt].in_num =3D iov_truncate(elem[elem_cnt].in_sg, > >>>> +=09=09=09=09=09=09 elem[elem_cnt].in_num, > >>>> +=09=09=09=09=09=09 size - current_size); =20 > >>> > >>> Will elem[].in_num always end up with the same value as the @in_num > >>> parameter? If so, do we need the explicit parameter? =20 > >> > >> @in_num parameter of vu_collect()? > >> > >> @in_num is the sum of all elem[].in_num, it can be computed by the cal= ler function from > >> elem, but it is simpler to return it as we need to compute it in the l= oop. =20 > >=20 > > 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. > >=20 > > 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? =20 >=20 > For an element, *=C3=ACn_*num is the number of *in_*sg we have read from = the ring for an element. >=20 > It's virtio semantic, so *in_* means sg going *in* the guest. Sure, that's fair, and: > For *out_*sg we have *out_*num. ...we certainly can't call it "out_" because of that. My problem is that "num" together with that becomes quite unspecific. > > What if we rename it to @in_used or @in_collected? >=20 > The idea was to keep the same name as in the element. But we can change t= his to @in_used. Oh, I see now. Maybe let's wait for David to comment, as maybe he was confused by the whole naming as well (my guess at least). --=20 Stefano