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=Hw63uJmY; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id A86765A0262 for ; Fri, 20 Mar 2026 21:58:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774040301; 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=qAsP+b5lh+APTIsysSuQ5eY59NhWSXJ0jdsqxTmfK8Q=; b=Hw63uJmYOr3A2+UVxQjAdnlZtN3lW1zsMhZrxamA1ZvIzLie29aPM+wWLO5oSYPMw8arly eHm0QLpHW4BC1Bef8/TFKPk5iyOUNQG9Qi/MEYG5lIukqo10PZ/IA1J90z2BYKvi2aB4we M2uWjafC91k6ZURV1AtmFIoziV44/OQ= 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-10-fS1CKCLBNEmZi3iqc4Dfjw-1; Fri, 20 Mar 2026 16:58:20 -0400 X-MC-Unique: fS1CKCLBNEmZi3iqc4Dfjw-1 X-Mimecast-MFC-AGG-ID: fS1CKCLBNEmZi3iqc4Dfjw_1774040299 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-439b8bc43aeso1288519f8f.1 for ; Fri, 20 Mar 2026 13:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774040299; x=1774645099; 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=qAsP+b5lh+APTIsysSuQ5eY59NhWSXJ0jdsqxTmfK8Q=; b=NPNNLTkkNqbTh1brXQQhk+M4kySu7n5szkH0jsIhpV4QxxJM+i5bI6UGXV2hNkW6ZL EY7ufuuKt3Ihoo4FRPrv2qF/lQvlv7fgs+Y56dFsh8xi9Qv5RpG/48I125O8J7wJ+kUZ 0lk76DQy8KHFeyFDCFqKk26uoONvI/j7jONBgluca5rF6hK5fynD7fPY2lBMwPrUgNSC DvT2xqBCX0jedqWWK/LfYkX7BwDMMUNS25QW3Vl2osxhX4WCn4ERZFbiov/Pb52Xq//I hO9L3+ghHW2S1vJcu+E0u+DZjOvqtsYXxb9cEllY1oD86TtgSU3a7kdjtg7KJQOPzTHE WUjQ== X-Gm-Message-State: AOJu0YxHgFLsg4nxgilw1xQ/oXJb9nRDjKZLV1/lEmWwfYVlAaPWrI3T s+vrJUcBnpVu+/NdPZPhKspwpJt4qAt7qPAXskuhRjzdIueD0D2NozkYECMP+mjT3rB9PNTmrWO qyCSumW8GDWNHjl81wafrEudj1Mny7HEUaF4PF3ynqmPxiKr8LglvWA== X-Gm-Gg: ATEYQzzHT/Iimb2dj3JiNqB5p+FVTQTuI1qcdA5N2ibwbCSbmOHy9YA50MyJVf87+eY LJlhFA1H8WfYUO22nejrRFboawOwE7YrbDR5iE/EFnUGrroaa6PpEw93o+C/wtIFszfAOcetRWr ycRlFchK5UAGSWuYavSueng4N/Ra9cKEqig/9LFseepMlE3S2Huxu+pTWKQqCElCAWFGVAf5QL8 JEriJqkz3wwx+NbxugFbDOGDU6tZxmp8jCI/WAZrYntmPUnFf4sZTClJ+8yyFPWikNw6kkw8NQx 6rWAgkEEmv5pJ6AMfckFwHRjfo2u9Vi9Aoni2JOdfEaXLLnHcrH2aykzPiaBIqIThmCzQNwg1ii h9Gc+QKjzUgFjvPFERr4ziCPSKyYD87Ux X-Received: by 2002:a05:6000:400b:b0:43b:4966:744a with SMTP id ffacd0b85a97d-43b6428ab1amr7635933f8f.50.1774040298912; Fri, 20 Mar 2026 13:58:18 -0700 (PDT) X-Received: by 2002:a05:6000:400b:b0:43b:4966:744a with SMTP id ffacd0b85a97d-43b6428ab1amr7635916f8f.50.1774040298500; Fri, 20 Mar 2026 13:58:18 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b644bd923sm10601337f8f.12.2026.03.20.13.58.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2026 13:58:17 -0700 (PDT) From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v3 0/3] Decouple iovec management from virtqueue elements Message-ID: <20260320215816.052d2be8@elisabeth> In-Reply-To: <20260318091941.2652278-1-lvivier@redhat.com> References: <20260318091941.2652278-1-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: Fri, 20 Mar 2026 21:58:17 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -lxm1cW95xskhqGD1Vkmxj9O7N1QuXzLm4lHVujwCec_1774040299 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 27BAKDDFLOIRX36Y4ULINDNRFOJ6GDLV X-Message-ID-Hash: 27BAKDDFLOIRX36Y4ULINDNRFOJ6GDLV 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: passt-dev@passt.top, David Gibson 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 Wed, 18 Mar 2026 10:19:38 +0100 Laurent Vivier wrote: > This series prepares the vhost-user path for multi-buffer support, > where a single virtqueue element can use more than one iovec entry. > > Currently, iovec arrays are tightly coupled to virtqueue elements: > callers must pre-initialize each element's in_sg/out_sg pointers > before calling vu_queue_pop(), and each element is assumed to own > exactly one iovec slot. This makes it impossible for a single element > to span multiple iovec entries, which is needed for UDP multi-buffer > reception. > > The series decouples iovec storage from elements in three patches: > > - Patch 1 passes iovec arrays as separate parameters to vu_queue_pop() > and vu_queue_map_desc(), so the caller controls where descriptors > are mapped rather than reading them from pre-initialized element > fields. > > - Patch 2 passes the actual remaining out_sg capacity to > vu_queue_pop() in vu_handle_tx() instead of a fixed per-element > constant, enabling dynamic iovec allocation. > > - Patch 3 moves iovec pool management into vu_collect(), which now > accepts the iovec array and tracks consumed entries across elements > with a running counter. This removes vu_set_element() and > vu_init_elem() entirely. Callers that still assume one iovec per > element assert this invariant explicitly until they are updated for > multi-buffer. > > The follow-up udp-iov_vu series builds on this to implement actual > multi-buffer support in the UDP vhost-user path. > > v3: > - rebase and add David's R-b > - fix coding style (if) > - rename in_num to in_total Applied. I took the liberty to add David's Reviewed-by: back on 3/3 as the only change in 3/3 v3 compared to v2 was actually something he suggested. -- Stefano