From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202608 header.b=pguOCW1M; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id DEF095A0262 for ; Mon, 17 Aug 2026 02:39:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202608; t=1786927171; bh=pg65xWZ9Q/ImM70tT5b/1BzOLCjHAyx41HI8CDJ1RKE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pguOCW1MU4+KhRybkwMXKBLx/Ma7qXpLzZ9EWy6+Q3yWmN0ZQ7+9EzbBYR+tiVQbb L7re/webVDshCGHi7ahilLZBy5kPOd4eR/3TUkjeiiUEPMVOa3Rac12mExOfPPAuLD EvtweEWv7RtX67iKNwR2FbAk9sFv9bV3H10iSZu2yG3oYYp3kYJOqljCXPBl9MruXg eCpvN2AuFYchkFpFq5OdXWqHPnOqKmfibImviJ9dYIRzCQYhEvDanHFCQ/BbHgFsi9 Qb6QuZC0SNm/cn0bua3DviQ3+pAnugWdmi9tC05nhp6lJU66A1++tOXBjjyP9zx4aN dYbPUv2UQe9OQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4hNYr31K9nz4w91; Mon, 17 Aug 2026 10:39:31 +1000 (AEST) Date: Mon, 17 Aug 2026 10:30:59 +1000 From: David Gibson To: Ammar Yasser Subject: Re: [RFC v3 4/8] virtio: Define the pasta vhost interface Message-ID: References: <20260802132155.870796-1-aerosound161@gmail.com> <20260802132155.870796-5-aerosound161@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NfkIEmcrGHxaK6u5" Content-Disposition: inline In-Reply-To: Message-ID-Hash: 2QA5N5LLZG3ACM6XHM7BL7RZX73RUCYG X-Message-ID-Hash: 2QA5N5LLZG3ACM6XHM7BL7RZX73RUCYG X-MailFrom: dgibson@gandalf.ozlabs.org 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: --NfkIEmcrGHxaK6u5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 16, 2026 at 08:39:29PM +0300, Ammar Yasser wrote: > On Thu Aug 13, 2026 at 4:16 AM EEST, David Gibson wrote: > > On Wed, Aug 12, 2026 at 08:17:19PM +0300, Ammar Yasser wrote: > >> On Mon Aug 10, 2026 at 5:06 AM EEST, David Gibson wrote: > >> >> =20 > >> >> /* Large enough for ~128 maximum size frames */ > >> >> -#define PKT_BUF_BYTES (8UL << 20) > >> >> +#define PKT_BUF_BYTES ((8UL << 20) + 1536) /* 128 * sizeof(virtio= _net_hdr_mrg_rxbuf) */ > >> > > >> > I think the rationale for this change needs to be clearer (granted, > >> > the comment here beforehand is also kind of confusing). IIRC - and > >> > based on the "~" in the comment, I don't think there's a strict > >> > requirement that this can hold 128 full frames - that's just setting= a > >> > reasonable sense of scale, and then a round number was picked near i= t: > >> > ~64kiB * ~64 ~=3D 8MiB > >> > > >> > So, I'm not sure if this change is necessary - if it really is, we > >> > need a clearer analysis of why. > >>=20 > >> Because pkt_buf is now going to be the buffer where vhost guest->pasta > >> data but with the added size of the virtio_net_hdr_mrg_rxbuf for every > >> frame. So this is accounting for the worst case where the guest wants = to > >> send a full 128 frames at maximum size at a time. > > > > Right, but that's not enough. AFAICT pkt_buf is sized to allow > > *roughly* 128 full packets, but it doesn't strictly have to be able to > > contain that many. If there's a reason it *must* have room for 128 > > full frames with vhost-kernel, that needs to be pointed out > > explicitly. >=20 > Are you saying the size is not enough or the explanation is not ? Sorry, I meant the explanation. > Also no, there's no explicit reason why it needs to have that many > packets in vhost-kernel. I saw that this was how pkt_buf was sized > before the vhost-kernel changes so i only added acounting for the virtio > net header Right, that's the point I'm making. I think having an aligned size fot the whole buffer is probably more valuable than being able to contain exactly 128 frames. > >> >> +#define VHOST_NDESCS (PKT_BUF_BYTES / 65520) > >> > > >> > I'm not sure 65520 is the right number here. That's the max MTU at > >> > the IP level, but the packet buffer will also hold the 14 byte L2 > >> > header. I think you probably want one of the L2_MAX_LEN_* constants > >> > (or to define a new one for vhost-kernel). > >>=20 > >> My line of reasoning here is that "we typically expect, in the majority > >> of cases for an ethernet frame to span a single descriptor". evident by > >> how we eventually consume descriptors as we return the pointer into the > >> pkt_buf past the virtio_net header as the beginning of an ethernet > >> header. and this buffer should handle 128 frames (from the definition= =20 > >> of PKT_BUF_BYTES) and so we want a denominator that yields a value as > >> close as possible to 128. Let me know if this isn't very sound. I will > >> investiagate the constants you mentioned anyways > > > > If the fundamental property you want is that you can fit 128 > > descriptors, then you should just define NDESCS as 128, and derive the > > buffer size and other things from that. If the basic property you > > want is something else, define that first and the rest in terms of it. >=20 > Fair enough, can do that=20 >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --NfkIEmcrGHxaK6u5 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmqCVj8ACgkQzQJF27ox 2GemcxAAoiaPfzpiGKxYqa6T5NHpPfzERb0wBSua/hsyzJVUDKMRoiESH5vH8Qx+ m1wABmXF2PBCsau5GCmj2Y7yKhf4OVwDQkdSVa/zdMEwxG7BB5NkRAw4i1pmRDbl vufWxlmLrNDJgPvaVd8ktGnLK5D3Al1FNcGzlOQFgPJaGFwodTNvy4D0TkPT3T31 lZUUcMeY17lD5jQuLVc5lMTKh0688CHjtry7+dhFQcqe1vf7rottxua/XWSg5zyR k/KwJ1+K/gl1UPXxubeb6PjqMHO//ANXC6Pn4slJE+bTQkhPSbYW5SxaRkyqvnMx /Mgx0Ed0z84x4Q3DVlZEoGmAm29g3+0t284DZdkBbyb8aV+wBV1L4+0cz9vyR7ze BLMyfxCd16QokbByc4UvVxbooXvkZmGhOf6vr3U1zL6vSgjzL+daaF77MHZ4xbDJ 4O93EzMxLszb7RHZq8aefQrjak3+8jyzFbCvr3aBjHVV9oT3CcrDbW7ZK5n7kjDV PO+RckERDm0g6l/Yu2CDO/OUmGW8kyKzQRpjQLKz+OdQaCp0P2POZXoQflh6fmrY U7svLv6fUgvtlM/dbHv7Pchdsy+46CLMoJQDTP69/RhJzBxdButFbvFVRcZXSn8M I0Nhy2y9dLUtkmCsOZw894q7sELAUmRSZYVsjnY3mB+iDrDj4K4= =RpQw -----END PGP SIGNATURE----- --NfkIEmcrGHxaK6u5--