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=DuV57qHs; dkim-atps=neutral Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by passt.top (Postfix) with ESMTPS id 978625A0272 for ; Sun, 16 Aug 2026 19:39:33 +0200 (CEST) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-c197e7e4e94so468367166b.2 for ; Sun, 16 Aug 2026 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786901973; x=1787506773; 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=nsAnTLrDdThQVKGW9S15gu4A9T4sy8eGJ/sYvS7lYm4=; b=DuV57qHsaMk9NpFL24rFvoceedtn+Zp4UG9JIaRdMz9CoTXywH2HNQPbexAU/tYDKh 4IDxqB0zNGRl3n6/AhJ40RbyPWHeL6l2GySPFOW5OU9I7427azQuidwr+pXzai4MV+x5 aM0mqwyKRxWpdAqOA3Hy1YLrOOk3xaq0Jj4nsUho2JAz4YiBjTDRY/h9VfdvSgXVRM+l TeKE6k6ZOnw12vfTwg3EvzJuDGSgDPPYnwqxcY3ajrJZHXSDD7XKEp9sjPpY3eaOELr7 mK9dwygLNjNO7alhhSfsbIgmHzH3Z39dBgAnfpA3nmSryG3UaK1KtuL4CSv5qhpKT+io Vdxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786901973; x=1787506773; 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=nsAnTLrDdThQVKGW9S15gu4A9T4sy8eGJ/sYvS7lYm4=; b=RY1nPaf+fbBesIGqmQ7oLIIi8A8tLC+B8J44cIPWPa0Bg/OsfBFovzwaRVMuGtoWxq zSwwB8RtiWA5BJcD/U6V3KXZztmHTiPo89wVL9IIXpY0Dt/KSwxv2aCQFvlqLm89WBOY 7r2AZsOhV2oby+phI4eaKYK2ZGnygzBziP1+DtQ7Ji+fgDAuOPQLkFXg9s59pMFCQHmA s3IyLiktUeG+ognS1edp+cks2E1x471fgm7KtoID0YqEFcu8VD965nwnyOzPa/cxQQy5 33QtzAQsvZ8B7vjb685u9XS8RxOG8yHgcGAlSDsQXCp5ijSEGWs7Jl9ITFAv4Wn0tgu3 7MEQ== X-Gm-Message-State: AOJu0YyolipKVUz0v6qjg0Dv9UJh5QVcW3wlK21ifVUCtb30Y+l1MqZL XWh/3wBdyhSAG/WEOL49GKn2mDYEZcIo5UMBM3DZJTcWdc8mPRTNiVxm X-Gm-Gg: AR+sD13GuQR8gmeDuHZCSOZ2wCHlNDsrGobTFooZk+K9rn0fMEYk40rhbf3xzjd1KpX kYRmYZ3m8ZVKXAURh4Beww8Aqb5yRfl8qgkvVe4wu8Pi8bE2I8IRN1Qa6+XHki3Zx2f8Tz8nFaM XMw3YNWS6K73iZOkkhCDm6SMFoJ1xdwy8PO8lEpuKbVsgCB7RA3uWsej8OaE7Gvj5gZ5CR8de/J DIx9UKnFXRP7zt9AaAVa1ZDRo5RzZtfuOpXx2RGXCv7oKV0GsUjcomXK36q9xTPiujMqscWpwZ2 +8dEyWhPL4rKpLeJWTPwoJ3COm1gKpnCF0NsTpfEvRekqQm/Dsn2eb0w2DO62z5POgFTBXjdkYA KvuSGc//mR7H74TKFSTTtvZE46pLYDdJ8+gXxXNXMTrrk7NSadclYRt74QWCHd3nBsrcfrZUQCP z01+VRPIuCKuajlKOgautbcjsLbt3tVcvS+XhHa5ufWBbDgFSGrhOp6J1cwZHcn7TGv+GycqhvS qsGp1cuyTN03b0OdCYBDlrEQRlm7CjI/00mM7ws/DtoL/uJteVKNg== X-Received: by 2002:a17:907:9614:b0:c15:f598:60c0 with SMTP id a640c23a62f3a-c212a09048bmr933289066b.4.1786901972602; Sun, 16 Aug 2026 10:39:32 -0700 (PDT) Received: from localhost ([196.137.36.17]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c21233a18b0sm359550766b.8.2026.08.16.10.39.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Aug 2026 10:39:31 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 16 Aug 2026 20:39:29 +0300 Message-Id: Subject: Re: [RFC v3 4/8] virtio: Define the pasta vhost interface From: "Ammar Yasser" To: "David Gibson" , "Ammar Yasser" X-Mailer: aerc 0.21.0 References: <20260802132155.870796-1-aerosound161@gmail.com> <20260802132155.870796-5-aerosound161@gmail.com> In-Reply-To: Message-ID-Hash: JGNKHRZYWLMBES4PKJ5IE4M4D4J346IX X-Message-ID-Hash: JGNKHRZYWLMBES4PKJ5IE4M4D4J346IX 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: 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_n= et_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 it: >> > ~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. Are you saying the size is not enough or the explanation is not ? 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 >> >> +#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. Fair enough, can do that=20