From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 140C6C54E41 for ; Tue, 5 Mar 2024 19:40:16 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1017410F1C1; Tue, 5 Mar 2024 19:40:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.b="cPMvx4Zv"; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="JlMxRde3"; dkim-atps=neutral Received: from wflow2-smtp.messagingengine.com (wflow2-smtp.messagingengine.com [64.147.123.137]) by gabe.freedesktop.org (Postfix) with ESMTPS id BAD1910F1C1 for ; Tue, 5 Mar 2024 19:40:13 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailflow.west.internal (Postfix) with ESMTP id C01C42CC021F; Tue, 5 Mar 2024 14:40:07 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Tue, 05 Mar 2024 14:40:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1709667607; x=1709674807; bh=/FrVbuG+NmXdRaEhMkfyj7JdlCIJB5MvqaHthubPGLI=; b= cPMvx4Zv2YoBIkL8xsE7Kw8/B90EvpPWMuFqT908td/fDqbbJ/EkWQFzK0Hy3reO wy/kOMD4gaX5VmyMxrKqFBE/7DSCRTUsKCSEpFUH8GJGKnXTjgFK055Sy4Mc0atB xVfzXYkCV8bCAUP6T5xsoBB67HXYLaJ86uAT5/JrCTrBzClb4O87cfVyUkzgMYLe ceIazN91U9vao0obIvn24T7gpfGeNbefC5M2MqvzRBG/n+HfgTSLqx9tsH6eVsrs kGPxOc3QSeh/ewvkWq493K+TzTsJTYL+BYkeZDTGBvpkILIUxIp80/mk/CS9ZEmL 6GNNgHPfBR7YI0JylkqKgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1709667607; x= 1709674807; bh=/FrVbuG+NmXdRaEhMkfyj7JdlCIJB5MvqaHthubPGLI=; b=J lMxRde3ko4PJQTtjaUXgAei17Q/G4wbmF53bN5Taddc0ZMMr1vEkooyUpR5UCz2/ sABteFvwgOFD4ygXhGI5F9wkZQp/YnFYKPkN3EoPTzLLBkUdyBZZ5Rymwi2u901b pxUZCM2V5zkwLsZsCiBa3cVZQLqzO+IEI8eiEq+QEAlSgkIm0aZ3x/rI4XX6yWyL xluEz90B+1jW1nyo9QMdzbeBxn8+M+3Xwh60Od7G6bz1SIAOaRtH94ZbQ8SeHZxJ yDNp6Pgy5EOnYneBDlAAPmQMG7H8br2SUKfhLK5cIsx0pzEq1Vx+gv+it257b1HG L2NhPYDf9sBgom+tdewRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrheelgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdet rhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrg htthgvrhhnpeegfeejhedvledvffeijeeijeeivddvhfeliedvleevheejleetgedukedt gfejveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id DD7D2B6008F; Tue, 5 Mar 2024 14:40:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-208-g3f1d79aedb-fm-20240301.002-g3f1d79ae MIME-Version: 1.0 Message-Id: In-Reply-To: References: <20240305020153.2787423-1-almasrymina@google.com> <20240305020153.2787423-13-almasrymina@google.com> Date: Tue, 05 Mar 2024 20:39:44 +0100 From: "Arnd Bergmann" To: "Mina Almasry" Cc: Netdev , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Linux-Arch , bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, "David S . Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Jonathan Corbet" , "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Andreas Larsson" , "Jesper Dangaard Brouer" , "Ilias Apalodimas" , "Steven Rostedt" , "Masami Hiramatsu" , "Mathieu Desnoyers" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Song Liu" , "Yonghong Song" , "John Fastabend" , "KP Singh" , "Stanislav Fomichev" , "Hao Luo" , "Jiri Olsa" , "David Ahern" , "Willem de Bruijn" , shuah , "Sumit Semwal" , =?UTF-8?Q?Christian_K=C3=B6nig?= , "Pavel Begunkov" , "David Wei" , "Jason Gunthorpe" , "Yunsheng Lin" , "Shailend Chand" , "Harshitha Ramamurthy" , "Shakeel Butt" , "Jeroen de Borst" , "Praveen Kaligineedi" , "Willem de Bruijn" , "Kaiyuan Zhang" Subject: Re: [RFC PATCH net-next v6 12/15] tcp: RX path for devmem TCP Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 5, 2024, at 20:22, Mina Almasry wrote: > On Tue, Mar 5, 2024 at 12:42=E2=80=AFAM Arnd Bergmann = wrote: >> On Tue, Mar 5, 2024, at 03:01, Mina Almasry wrote: >> >> This structure requires a special compat handler to run >> x86-32 binaries on x86-64 because of the different alignment >> requirements. Any uapi-visible structures should be defined >> to avoid this and just have no holes in them. Maybe extend >> one of the __u32 members to __u64 or add another 32-bit padding field? >> > > Honestly the 32-bit fields as-is are somewhat comically large. I don't > think extending the __u32 -> __u64 is preferred because I don't see us > needing that much, so maybe I can add another 32-bit padding field. > Does this look good to you? Having a reserved field works but requires that you check it for being zero already, so you can detect an incompatible caller. > struct dmabuf_cmsg { > __u64 frag_offset; > __u32 frag_size; > __u32 frag_token; > __u32 dmabuf_id; > __u32 ext; /* reserved for future flags */ > }; Maybe call it 'flags'? > Another option is to actually compress frag_token & dmabuf_id to be > 32-bit combined size if that addresses your concern. I prefer that > less in case they end up being too small for future use cases. I don't know what either of those fields is. Is dmabuf_id not a file descriptor? If it is, it has to be 32 bits wide. Otherwise having two 16-bit fields and a 32-bit field would indeed add up to a multiple of the structure alignment on all architectures and solve the problem. Arnd