From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=P4gL6iH6; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 693485A026F for ; Wed, 01 Jan 2025 22:54:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735768480; 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=UFoASstoSwDBZzCzRaXFKuOW7o4gJyPDj8wuF3XMiIg=; b=P4gL6iH6fjFn4yDg1a9/+cRCtrilEijEyP8Eo1LYqJWbs2llNyPgCEt/j6MSfX5mozaAZr 68Y3WjlQe5aLjd6vtLVd9lCeiylcfX3vzh5N1uDpOFLz6GtCozgBOqzpezqqvYIzCelcNP 2GoEpbx32gDe/nkNPvzEr3+cXIxmLPs= 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-333-5INL6tRwM7eabEbGDNnlwg-1; Wed, 01 Jan 2025 16:54:38 -0500 X-MC-Unique: 5INL6tRwM7eabEbGDNnlwg-1 X-Mimecast-MFC-AGG-ID: 5INL6tRwM7eabEbGDNnlwg Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-43651b1ba8aso76240045e9.1 for ; Wed, 01 Jan 2025 13:54:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735768477; x=1736373277; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UFoASstoSwDBZzCzRaXFKuOW7o4gJyPDj8wuF3XMiIg=; b=LLLtrNbHiZH6Q89iO4cVpSOg0XD5LvMq2xg0J3ix2e6FgZl7YA70ie+UTngF6bcudF 8VMZcXnemgdnj8p97Kw+/nPEKVYZp4aMjLtzA7/kBz0n6jXwMBUJnW3sieJbt6LB7Bz6 ufwQgYRBo9sIbGpm1uhMZbzGT6SjpbZR4aBgYEy2ljcI9ip7w1P2Mk/RRSb3wzRYmGGx p+XCQxa7W87X/xg+8LJJqVsC7OusVfPtcVr9xmRTwvL5GwEx8uUU62YXsu5Enp6Ww+eN IroheJlm6M2PyyhiCfVTRQGcmBGmsh7lkpMxdfJT+8R2QEobYBqEXmNRGdmKIqo0RPrr 1vyw== X-Gm-Message-State: AOJu0YyW2h/XWt8rxFKih55GguNLh1FaRIzuJ8Aoq/UMGDmbhIu5ipLM neAJnORPJUrEaoQQdV8U5sI661wUyqA0IWCOcpqZrcefT/ZJ8ELbi/yxZ+0zaqpE70d45cTNp5N a732hzMKeMCc8YuZmihfBerRQC9ZGmjMgzC8rfJjzHvkFrhL1XaZvXttQcw== X-Gm-Gg: ASbGncs3o81qoO+Af4keEBrU4cd9sXbY+6jKz5L3L1mYOvV1pfMquNllhDhLwViryDo DS7ihIc1ROR6Ht2jevQ1Z1Hf15QS40npH3WgSR28dQf3qzSy04ck3jN9LjkgtMBi1PWAct3dLkO CItK1slY3asrQCWdyLFCqO1BbqFkPif+X6DguLuuYXlm/BRfsDf7fq3AA+Q2CV7/xd6YQMpZ72m 53bUhgtcbwhgX9J1cbVWAo/FbJqkOnK1MUTG47XFcB2Lbfw4XLNfYGE3AJd6G0MC7Pc3/RmjNxX +5Fd4ByndQ== X-Received: by 2002:a05:600c:4509:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-4366864722emr395584335e9.17.1735768476961; Wed, 01 Jan 2025 13:54:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IHF8LKrvFkZZcNGNAnxOhVojFrHpjdmiAQN68BnMm1lq7VOoabGi9WdLgof8BiE3U4pP+5zyw== X-Received: by 2002:a05:600c:4509:b0:436:1971:2a4 with SMTP id 5b1f17b1804b1-4366864722emr395584205e9.17.1735768476551; Wed, 01 Jan 2025 13:54:36 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c828817sm37025887f8f.1.2025.01.01.13.54.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jan 2025 13:54:35 -0800 (PST) Date: Wed, 1 Jan 2025 22:54:33 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v2 06/12] packet: Don't hard code maximum packet size to UINT16_MAX Message-ID: <20250101225433.45f52b86@elisabeth> In-Reply-To: <20241220083535.1372523-7-david@gibson.dropbear.id.au> References: <20241220083535.1372523-1-david@gibson.dropbear.id.au> <20241220083535.1372523-7-david@gibson.dropbear.id.au> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: mVsUZDHP1UcfCsoaGhgJhLetzX8U_kzaVlnGfuPRzig_1735768478 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: KXB76KROSRNCUORTGFWKPR3H375KQSO7 X-Message-ID-Hash: KXB76KROSRNCUORTGFWKPR3H375KQSO7 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 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 Fri, 20 Dec 2024 19:35:29 +1100 David Gibson wrote: > We verify that every packet we store in a pool - and every partial packet > we retreive from it has a length no longer than UINT16_MAX. This > originated in the older packet pool implementation which stored packet > lengths in a uint16_t. Now, that packets are represented by a struct > iovec with its size_t length, this check serves only as a sanity / security > check that we don't have some wildly out of range length due to a bug > elsewhere. > > However, UINT16_MAX (65535) isn't quite enough, because the "packet" as > stored in the pool is in fact an entire frame including both L2 and any > backend specific headers. We can exceed this in passt mode, even with the > default MTU: 65520 bytes of IP datagram + 14 bytes of Ethernet header + > 4 bytes of qemu stream length header = 65538 bytes. > > Introduce our own define for the maximum length of a packet in the pool and > set it slightly larger, allowing 128 bytes for L2 and/or other backend > specific headers. We'll use different amounts of that depending on the > tap backend, but since this is just a sanity check, the bound doesn't need > to be 100% tight. I couldn't find the time to check what's the maximum amount of bytes we can get here depending on hypervisor and interface, but if this patch fixes an actual issue as you seem to imply, actually checking that with QEMU and muvm would be nice. By the way, as you mention a specific calculation, does it really make sense to use a "good enough" value here? Can we ever exceed 65538 bytes, or can we use that as limit? It would be good to find out, while at it. -- Stefano