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=ONLZOk00; 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 12E125A0262 for ; Wed, 20 May 2026 02:52:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779238333; 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=Lw/e6s4d1w19hMoxvtrPQFgyGbgp9bQ4LAYWDwT0igQ=; b=ONLZOk00WdRW0n5xe6CSh4rg2tDGMm4aJdVGMJhkIxtRiIc9XTHmcVKrVE8UWCLFAuR7M1 nWRj6v4iLKH1pVPige0SxOeS5QyfuoqB2Q707UsQDdjCbePAFgwBx62B5Qtlc/ROf+uwZi 1QsE30t/B5QtT53mLVis/r3ZolK7VeM= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-362-MiFOIo-QO1mwbJIPGWK_Aw-1; Tue, 19 May 2026 20:52:12 -0400 X-MC-Unique: MiFOIo-QO1mwbJIPGWK_Aw-1 X-Mimecast-MFC-AGG-ID: MiFOIo-QO1mwbJIPGWK_Aw_1779238331 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48fe6894f3fso24716695e9.2 for ; Tue, 19 May 2026 17:52:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779238331; x=1779843131; 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=Lw/e6s4d1w19hMoxvtrPQFgyGbgp9bQ4LAYWDwT0igQ=; b=e6s0IHJuquNZCtRmIaxtCOAhRXeAiABFNx3rVnGCjvwlFthDnxm+7hOLSkCYakEUE4 Pzxl/f4LpjOyXyWwB2d6N2CS9qiUuPaId33XTPQZzwGA+Q2oZNuHYls6X5CantznRI/h XHxBGE+bnhgU1d1WW2DSevXvrW56QF3CbPvB6YDT9aRSFtF3mV8exrXUhvbGhdT/1KzS eG4mAAxDQ4zS+cLKiFkF/B3USsTfkgHHRNtv909SDJkRSg5b+3wvbFS4htEIOQMg8+zm G1sB3Pi9dMX0mHsrwI7m4pRFFIDqStEhySgXxAL0/hQcTlojc8nph/Un3Jbew0wmyQQY oQTQ== X-Gm-Message-State: AOJu0YyPZd48OYoo5Z5BXbyBWWMbkbBCAGZChnTq9ydj0aGyjcbYQWdO +X74oF0OFCOXlT884pkOEAFOWEvxdixOiOyTQWig8VlpGwnHXtc9rxDOrG7l9eIjkMbjVaWCTZ0 F1lfB13c/KG1lhrZnosvnMq9skHJ26OLsZWrrbsRLcAz1cox25FZ0Wg== X-Gm-Gg: Acq92OFTr6UZyKx/Qqafzl+diXJFSqwMfWw4Q2vi2xrU42UfESufkVuZYu/mTxT0pBu AN2eTwaKtlpCVKo0dlx+lddKATEZE98T7zaNXw92muLYO1SGhNa2PoC/HjMvTe34ag5JEdMGZ33 VN8f47joDrvshzFUa5GDmDXJb85uMdHE84IMP0I23WjSnVB9MZfp8eJh5uVGzoxvFl1Q4smlAzU 0PqVQiNZAbyPWJhQ+9IP3ZwjHLJFQHHEQbHQQ4TRvDP/y+mL1mlbT9+NH2uz6IOER6LsqvhNj8W MG0dPHBp3zIJDUIIkg2f5mqKI7OSCOYILL7TE3SdqHd10d+qngXOMq0W8kw/dOFEDKftxNPoaTH P8sC5yg64PlXoc5wk9UmkM0X3bco6eBhmaGTplVv7vToubADPUw== X-Received: by 2002:a05:6000:1247:b0:45e:6518:3299 with SMTP id ffacd0b85a97d-45e651832f5mr22062792f8f.5.1779238330946; Tue, 19 May 2026 17:52:10 -0700 (PDT) X-Received: by 2002:a05:6000:1247:b0:45e:6518:3299 with SMTP id ffacd0b85a97d-45e651832f5mr22062772f8f.5.1779238330482; Tue, 19 May 2026 17:52:10 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da15a6454sm50691509f8f.34.2026.05.19.17.52.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 17:52:09 -0700 (PDT) From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH v4 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element Message-ID: <20260520025208.5f31e61e@elisabeth> In-Reply-To: <20260513115218.1662850-1-lvivier@redhat.com> References: <20260513115218.1662850-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: Wed, 20 May 2026 02:52:09 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: tKGGF0KvyeerfniyM8lTw2Q0cLSVAmssLNCIa28SDeo_1779238331 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TFO5M77ZLQUHMD32CHWZKL5NY7S3ERJ5 X-Message-ID-Hash: TFO5M77ZLQUHMD32CHWZKL5NY7S3ERJ5 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, Jon Maloy , 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, 13 May 2026 13:52:08 +0200 Laurent Vivier wrote: > Currently, the vhost-user path assumes each virtqueue element contains > exactly one iovec entry covering the entire frame. This assumption > breaks as some virtio-net drivers (notably iPXE) provide descriptors where the > vnet header and the frame payload are in separate buffers, resulting in > two iovec entries per virtqueue element. > > This series refactors the vhost-user data path so that frame lengths, > header sizes, and padding are tracked and passed explicitly rather than > being derived from iovec sizes. This decoupling is a prerequisite for > correctly handling padding of multi-buffer frames. > > The changes in this series can be split in 3 groups: > > - New iov helpers (patches 1-2): > > iov_memset() and iov_memcpy() operate across iovec boundaries. > These are needed by the final patch to pad and copy frame data > when a frame spans multiple iovec entries. > > - Structural refactoring (patches 3-5): > > Move vnethdr setup into vu_flush(), separate virtqueue management > from socket I/O in the UDP path, and pass iov arrays explicitly > instead of using file-scoped state. These changes make it possible > to pass explicit frame lengths through the stack, which is required > to pad frames independently of iovec layout. > > - Explicit length passing throughout the stack (patches 6-10): > > Thread explicit L4, L2, frame, and data lengths through checksum, > pcap, vu_flush(), and tcp_fill_headers(), replacing lengths that > were previously derived from iovec sizes. With lengths tracked > explicitly, the final patch can centralise Ethernet frame padding > into vu_collect() and a new vu_pad() helper that correctly pads > frames spanning multiple iovec entries. > > v4: > - rebase > - iov_memcpy: use size_t for loop indices i and j > - udp_vu: reorder elem[] declaration for inverted christmas tree style > - pcap: wrap pcap_iov() declaration and definition to respect line length > - write_remainder(): update length parameter description > - Add Reviewed-by tags from Jon and David Applied, sorry for the delay. -- Stefano