From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=Rn2KkmJD; dkim-atps=neutral Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by passt.top (Postfix) with ESMTPS id B52AF5A0272 for ; Sun, 16 Aug 2026 19:48:29 +0200 (CEST) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6a0a4aa99bdso3775311a12.1 for ; Sun, 16 Aug 2026 10:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786902509; x=1787507309; darn=passt.top; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=iNnCIB0TAcl300Jj7Gn99b4lyq5sEbKdjuq6r2Cp8/M=; b=Rn2KkmJDPX3PZi33hAlBRx2o3yK7rM+SV+LXpr2Gza1EJPQYkPvW7EzLKveFtEz/CV gYob8NC6hhMPXyfub2YrnHcfuC/f2QpaYrbOXRlUjJaGplntTYM8/dIEf4MPW2l1/Qxs WEagK4EYK4h++vNaISNFIIfJRV664x1sqqccVlYXMTaO9pLeIlCHZSX9tHeCWGTg4Plf 6eRQBa6xVpg3FgIdhNm4js0MqRS2IBFB+gBFS1fBpO/dAZPfd/k4Z8rWHPTCzkUMjHx1 Wy8dGFRsqFrk4vemIyuqgtJrPd8linqRENYnco22L8QDYNUKm+2DDRKYfMYrRFYGgw7h 1yLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786902509; x=1787507309; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=iNnCIB0TAcl300Jj7Gn99b4lyq5sEbKdjuq6r2Cp8/M=; b=mDXdXAzCbuV8acl96LaBWthKpTlx+sW0C0UQrikHrQIUyWeCOdTVdbQM14C4gitccW VFjtNbmNsY6ra/tNINk1Ey4BusbM1bLbXbW7HB/AUYxCnEXbs7gcwxhFbYt4HvozQAAG XuM3+p+tT8hfPuobu11mzPG/XbmDfryyDfhmrRjuRldBzzNBMIeU5U3QhJ/bnSojYlXK 1thvJ69sTu9tpOJXQyy/r1C9CVCtV0i/ys2baBTYXCE6JP1m2iIdebx9nusbl5uD9kTm oq7kxfq02tYzuZfmalsoJjXv7GscrkxPsJm0iVLh7C4hgZgnZzTENGb4qgfs3YJqk+pL Km2w== X-Gm-Message-State: AOJu0YxgJAF5AiaAM8OKjagwvjMYD2Zv+TfDIzPVDAhJThH+qf+drp5Q SkGpkK7p2qkzBqF+nom2VCp0Mb6fhSgYdPDGgBrMeJ+EmYQmhv2/ytOl X-Gm-Gg: AR+sD137LkWe2WCDLAzZ+QmkXY9MyPB/bVBdbUiP8MdYFU30TZsGr94erhTftB27OBE ayPNFkHnPmzzrEMDkJpsFyTI3U6zSbGW7UszAVI/WaD/apRRgoGXs0cpVOgjFJJ3pjngsQTuPCX khv+uZ41Bh2pCyj5uquz6CwTZtdehtxfNrJHZPVab2mfS2m7czrWmD5yIs2vac8e/UIWD6EXvyi fd/kveP0p2Mb3NSCGmGWCcZvgOqoLp550mGQaEoWyhGZgF+Ob8KIjx8FnhONe++G06rGU7FLVgK ESz/7ZykyozaR1JeCJ/CBMD+pFle8Cyapg1BTyL0zZj6PsQ0KxbDQR9bq+FBjBRvxEufuplBrpH 5+afyXaYCKjwIc77jYIZaQM12WIVwG/4ME1Z2ld2i+R4GCr7j2QSopmPDeQcOQ2YHNRrO+bmtOP gYt1fns8Trwa9n9rO7SNr7h21CIjbcF1kJUsM6DNIG16eIP4hKpFlNaGOTYfSohk5IdA+G4A7hb 1aCplk6WgMTzyeQCJYq0g5xkbSNATk= X-Received: by 2002:a17:906:f5a9:b0:c1c:4fce:6517 with SMTP id a640c23a62f3a-c212a108b9emr958862766b.11.1786902508765; Sun, 16 Aug 2026 10:48:28 -0700 (PDT) Received: from localhost ([196.137.36.17]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c213f43148esm282983866b.7.2026.08.16.10.48.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Aug 2026 10:48:27 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 16 Aug 2026 20:48:24 +0300 Message-Id: Subject: Re: [RFC v3 5/8] virtio: Implement the pasta vhost functions From: "Ammar Yasser" To: "David Gibson" , "Ammar Yasser" X-Mailer: aerc 0.21.0 References: <20260802132155.870796-1-aerosound161@gmail.com> <20260802132155.870796-6-aerosound161@gmail.com> In-Reply-To: Message-ID-Hash: TB42YNCJSJY2XNTZ75IW53L5MZ3TLXZ4 X-Message-ID-Hash: TB42YNCJSJY2XNTZ75IW53L5MZ3TLXZ4 X-MailFrom: aerosound161@gmail.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, eperezma@redhat.com 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: >> >> + /* general purpose buffers */ >> >> + vhost_memory.mem.regions[0] =3D VHOST_MEMORY_REGION(pkt_buf); >> >> + vhost_memory.mem.regions[1] =3D VHOST_MEMORY_REGION(eth_pad); >> >> + >> >> + /* tcp specific buffers */ >> >> + vhost_memory.mem.regions[2] =3D VHOST_MEMORY_REGION(tcp_payload_= tap_hdr); >> >> + vhost_memory.mem.regions[3] =3D VHOST_MEMORY_REGION(tcp4_payload_ip= ); >> >> + vhost_memory.mem.regions[4] =3D VHOST_MEMORY_REGION(tcp6_payload_ip= ); >> >> + vhost_memory.mem.regions[5] =3D VHOST_MEMORY_REGION(tcp_payload); >> >> + vhost_memory.mem.regions[6] =3D VHOST_MEMORY_REGION(tcp_eth_hdr); >> >> + >> >> + /* udp specific buffers */ >> >> + vhost_memory.mem.regions[7] =3D VHOST_MEMORY_REGION(udp_payload); >> >> + vhost_memory.mem.regions[8] =3D VHOST_MEMORY_REGION(udp_eth_hdr); >> >> + vhost_memory.mem.regions[9] =3D VHOST_MEMORY_REGION(udp_iov_recv); >> >> + vhost_memory.mem.regions[10] =3D VHOST_MEMORY_REGION(udp_mh_recv); >> >> + vhost_memory.mem.regions[11] =3D VHOST_MEMORY_REGION(udp_meta); >> > >> > Not sure if there would be value in delegating these to helpers in >> > tcp.c and udp.c >>=20 >> You mean every protocol file registers its own memory regions through >> calling the macro and taking as input the vhost_memory struct ? > > More or less, yes. Specifically I was thinking that this function > would call, say, tcp_vhost_regions() etc. > >> It will be better in the sense that it will remove the need for making >> those buffers public. But i think it will be harder to follow from a >> readability perspective. WDYT ? > > It's a trade off. It's a bit harder to collate the complete set of > memory regions. However it avoids making the buffers public and makes > it clearer when looking at the TCP code that part of "its" memory is > shared via vhost. It also makes it a little easier to keep the shared > regions in sync if we change the data structures that (say) TCP uses > internally. The last point is pretty noteworthy. Yeah ok.. will go with functions per protocol that register the dedicated regions > >> >> + * rx_descriptor_handoff() - Batch-announce freed RX descriptors to = the kernel >> >> + * @c: Execution context >> >> + * >> >> + * Bumps avail.idx by the number of descriptors accumulated in >> >> + * vqs[0].num_free (from prior consume_one_rx_descriptor() calls), >> >> + * then resets the counter to zero. The kernel will see the new >> >> + * avail.idx and consume the freshly-available descriptors. >> >> + * >> >> + */ >> >> +void rx_descriptor_handoff(struct ctx *c) >> > >> > Can this be static? That's the sort of thing that's harder to review >> > when signatures are split from implementations. If not, it should >> > have a properly prefixed name. >>=20 >> If by static you mean it gets defined in only one place and not exported >> then its used in two places (virtio.c and tap.c). Unless you want a >> duplicate definition which i personally am not in favor of. > > Right, again, because the uses in different places are split across > patches, that makes it harder to see that it's used in multiple places. > >> Can you please clarify what you mean by a prefixed name ? Not sure i >> understand what a proper prefix to a function like this would be > > Usually (though not always) functions exported from one module to be > used in others have a name that starts with the module name. So in > this case it would be vhost_something_something(). The prefixed name sounds like a good idea. I think it may be difficult to restructure the series so that both uses of the function will be in one patch without this patch becoming super blocky. Going with the prefixed name solution