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 A44D3EB271B for ; Tue, 10 Feb 2026 21:10:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 65B1F10E5F4; Tue, 10 Feb 2026 21:10:16 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="e3bgbA3B"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id EAC3310E556; Tue, 10 Feb 2026 21:10:14 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6CDC043E5E; Tue, 10 Feb 2026 21:10:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5337C116C6; Tue, 10 Feb 2026 21:10:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770757814; bh=UWSb7wjpHsusRVvieXLpHdxv/4zDaCUkIgy7QUYN+Qw=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=e3bgbA3BYcAKRl8iwbdJVkgrkS7A1nttqBdEge3iUnUgQ4wnLXe5M9C/gQST9Vazx mTI9eXXs9l8hK1+3phBxmaosKEOsPCLxUv5EoIxnCTNTBXSuoHSTgXEX0nmjSSlBZX etqvR3ijBk3JxLIBdOJr71PBelaIdS29Pmh3twzOnqsJQaHHOvHi5vSYlOe+9p0kul amTGI376pQKDV+W8QZ05JdpeYMoYXT6yjUSFUxUT538ypdEgXgY3IbkeRQMh1ipnz5 4JBp6ySOVNWzst9QfT3XNGf2Nm6PjMXLJK3bbMV+LMDWQxjUetTaCqnbm7f9wN/NfH NKHT6RpV1wiCA== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 10 Feb 2026 22:10:02 +0100 Message-Id: Subject: Re: [PATCH -next v8 2/3] rust: gpu: Add GPU buddy allocator bindings Cc: , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Jonathan Corbet" , "Alex Deucher" , =?utf-8?q?Christian_K=C3=B6nig?= , "Jani Nikula" , "Joonas Lahtinen" , "Vivi Rodrigo" , "Tvrtko Ursulin" , "Rui Huang" , "Matthew Auld" , "Matthew Brost" , "Lucas De Marchi" , =?utf-8?q?Thomas_Hellstr=C3=B6m?= , "Helge Deller" , "Alice Ryhl" , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , "John Hubbard" , "Alistair Popple" , "Timur Tabi" , "Edwin Peer" , "Alexandre Courbot" , "Andrea Righi" , "Andy Ritger" , "Zhi Wang" , "Balbir Singh" , "Philipp Stanner" , "Elle Rhumsaa" , "Daniel Almeida" , , , , , , , , , To: "Joel Fernandes" From: "Danilo Krummrich" References: <20260209214246.2783990-1-joelagnelf@nvidia.com> <20260209214246.2783990-3-joelagnelf@nvidia.com> <1770754015.1979311.8126@nvidia.com> In-Reply-To: <1770754015.1979311.8126@nvidia.com> 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 Feb 10, 2026 at 9:09 PM CET, Joel Fernandes wrote: >>> +impl GpuBuddyInner { >>> + /// Create a pin-initializer for the buddy allocator. >>> + fn new(params: &GpuBuddyParams) -> impl PinInit { >>=20 >> I think we can just pass them by value, they shouldn't be needed anymore= after >> the GpuBuddy instance has been constructed. > > Dave Airlie specifically reviewed this in RFC v6 and recommended passing = by > reference rather than by value [2]: > > "maybe we should pass them as non-mutable references, but I don't think > there is any point in passing them by value ever." > > The params are also reused in practice -- the doc examples show the same > `GpuBuddyParams` being used repeatedly. References > avoid unnecessary copies for this reuse pattern. Well, that's for GpuBuddyAllocParams, those are indeed reused and shouldn't= be copied all the time. But my comment was about GpuBuddyParams, I don't see a reason those are reu= sed (neither are they in the example), so it makes more sense to pass them by v= alue, such that they are consumed. (I.e. I'm not asking for adding Copy/Clone.) > > [2] https://lore.kernel.org/all/CAPM=3D9tyL_Cq3+qWc4A41p7eqnNDLS1APUEeUba= QyJ46YDkipVw@mail.gmail.com/ > >>> + pub fn new(params: &GpuBuddyParams) -> Result { >>=20 >> Same here, we should be able to take this by value. > > Same reasoning as above. > >>> + pub fn alloc_blocks(&self, params: &GpuBuddyAllocParams) -> Result= > { >>=20 >> Why do we force a reference count here? I think we should just return >> impl PinInit and let the driver decide where to >> initialize the object, no? >>=20 >> I.e. what if the driver wants to store additional data in a driver priva= te >> structure? Then we'd need two allocations otherwise and another referenc= e count >> in the worst case. > > Good point. The reason I had `Arc` was to anticipate potential shared own= ership > use cases, but at the moment there is no such use case > in nova-core -- each `AllocatedBlocks` has a single owner. Sure, but drivers can always pass an impl PinInit to Arc::pin_init() themse= lves. > I'll change this to return `impl PinInit` in the = next > version. If a shared ownership use case arises later, we > can always add an `Arc`-returning convenience wrapper. I don't think we should, don't give drivers a reason to go for more allocat= ions they actually need for convinience.