From nobody Mon Jan 29 15:26:31 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TNsbT3FXcz58tkn; Mon, 29 Jan 2024 15:26:45 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNsbT06NTz4fKN; Mon, 29 Jan 2024 15:26:44 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 33A3D8D4A177; Mon, 29 Jan 2024 15:26:34 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1B3092D029D7; Mon, 29 Jan 2024 15:26:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id PaKNKvJKUKtQ; Mon, 29 Jan 2024 15:26:33 +0000 (UTC) Received: from strong-aiccu0.sbone.de (strong-aiccu0.sbone.de [IPv6:fde9:577b:c1a9:f491::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id ACD212D029D2; Mon, 29 Jan 2024 15:26:32 +0000 (UTC) Date: Mon, 29 Jan 2024 15:26:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 3be59adbb5a2 - main - vtnet: Adjust for ethernet alignment. In-Reply-To: <202401290514.40T5Eb1i061789@gitrepo.freebsd.org> Message-ID: References: <202401290514.40T5Eb1i061789@gitrepo.freebsd.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4TNsbT06NTz4fKN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] On Mon, 29 Jan 2024, Warner Losh wrote: > The branch main has been updated by imp: > > URL: https://cgit.FreeBSD.org/src/commit/?id=3be59adbb5a2ae7600d46432d3bc82286e507e95 > > commit 3be59adbb5a2ae7600d46432d3bc82286e507e95 > Author: Warner Losh > AuthorDate: 2024-01-29 05:08:55 +0000 > Commit: Warner Losh > CommitDate: 2024-01-29 05:08:55 +0000 > > vtnet: Adjust for ethernet alignment. > > If the header that we add to the packet's size is 0 % 4 and we're > strictly aligning, then we need to adjust where we store the header so > the packet that follows will have it's struct ip header properly > aligned. We do this on allocation (and when we check the length of the > mbufs in the lro_nomrg case). We can't just adjust the clustersz in the > softc, because it's also used to allocate the mbufs and it needs to be > the proper size for that. Since we otherwise use the size of the mbuf > (or sometimes the smaller size of the received packet) to compute how > much we can buffer, this ensures no overflows. The 2 byte adjustment > also does not affect how many packets we can receive in the lro_nomrg > case. Doesn't this still include at least these two un-asserted/un-documented asumptions: (a) mbuf space is large enough to hold 2 extra bytes? Is this always the case? (b) the struct sizes assigned to vtnet_hdr_size are not odd numbers of bytes? Could add comments or CTASSERTs? > PR: 271288 > Sponsored by: Netflix > Reviewed by: bryanv > Differential Revision: https://reviews.freebsd.org/D43224 -- Bjoern A. Zeeb r15:7