From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8BB780B; Tue, 13 Aug 2024 00:15:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723508152; cv=none; b=Rxu74Ij/+b3v6IHveGbcYp8yQzZJbbiiUOZBqmItA6WjtalSXVJUBvR0Il9KhpUdp9yfHqEyjZlSUdbAEHej9pOUgBz6P/oLa3YEnc4XfGi25+J9fIGEmRG76NG8gO+0dnXPXqCUM87GJych4LdqqXux2QUs7Hk7JXTWI5hzgUs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723508152; c=relaxed/simple; bh=S1XJ/Rz0CP+PA+3mSURlVDBTpHV1w7efu3oNCRizCkY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jHPIrdBLUV6NXkS48N2T47PEtrd92zCGTE19Yg6CPt39T9W5gg0OjnXWJjeuVL1XLO1JXvBteH6vkI9zLIV7jHeYW0xt5AAbmlpnDCyHZrbPeskgPX9w1nR6pzikN7EP8mOmGJ0Srfmp9Fh9DHPHHLyy8Wf2e7BXu9yI48q8jQ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AQm5zO/c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AQm5zO/c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D6C7C4AF0E; Tue, 13 Aug 2024 00:15:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723508151; bh=S1XJ/Rz0CP+PA+3mSURlVDBTpHV1w7efu3oNCRizCkY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AQm5zO/caWjx/0boPDLSn9iybZGi2E9coWEf8vuRSJQZxFonF6ZMTqNRdf16uoSCa VwE1WzgKVmX0nyQvbpgls5jI3pUxjVDgFpGWDenYKwnUaW60chOXGR7lkefPfATg+1 vBAWWTcYTsX1Lcgs1IKvy2oe7UfJqQyNo1o+QfSGRfaNuInEGL84+5SR+SfHh7l8fI V7fXA1AyV0xE9M5t7Flqo0i4T3GntLyIkd8sZcews0vKvH2nqbnRU6yLT6Dr5hQkXL meOJ/JxdpV+tg2ejXTwmE+baIIo1DOu1ervh33EeUjG1j9bXW6gAPX7UuKhT5J3WJx 1ANCH5J5uVR7g== Date: Mon, 12 Aug 2024 17:15:48 -0700 From: Jakub Kicinski To: Pavel Begunkov Cc: Mina Almasry , netdev@vger.kernel.org, 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@vger.kernel.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, Donald Hunter , "David S. Miller" , Eric Dumazet , 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 , Arnd Bergmann , Steffen Klassert , Herbert Xu , David Ahern , Willem de Bruijn , Shuah Khan , Sumit Semwal , Christian =?UTF-8?B?S8O2bmln?= , Bagas Sanjaya , Christoph Hellwig , Nikolay Aleksandrov , Taehee Yoo , David Wei , Jason Gunthorpe , Yunsheng Lin , Shailend Chand , Harshitha Ramamurthy , Shakeel Butt , Jeroen de Borst , Praveen Kaligineedi , Willem de Bruijn , Kaiyuan Zhang Subject: Re: [PATCH net-next v18 07/14] memory-provider: dmabuf devmem memory provider Message-ID: <20240812171548.509ca539@kernel.org> In-Reply-To: <71260e3c-dee4-4bf0-b257-cdabd8cff3f1@gmail.com> References: <20240805212536.2172174-1-almasrymina@google.com> <20240805212536.2172174-8-almasrymina@google.com> <20240806135924.5bb65ec7@kernel.org> <20240808192410.37a49724@kernel.org> <20240809205236.77c959b0@kernel.org> <48f3a61f-9e04-4755-b50c-8fae6e6112eb@gmail.com> <20240812105732.5d2845e4@kernel.org> <7e2ffe62-032a-4c5e-953b-b7117ab076be@gmail.com> <71260e3c-dee4-4bf0-b257-cdabd8cff3f1@gmail.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 12 Aug 2024 20:04:41 +0100 Pavel Begunkov wrote: > >> Also don't see the upside of the explicit "non-capable" flag, > >> but I haven't thought of that. Is there any use? > > Or maybe I don't get what you're asking, I explained > why to have that "PP_IGNORE_PROVIDERS" on top of the flag > saying that it's supported. > > Which "non-capable" flag you have in mind? A page pool create > flag or one facing upper layers like devmem tcp? Let me rephrase - what's the point of having both PP_PROVIDERS_SUPPORTED and PP_IGNORE_PROVIDERS at the page pool level? PP_CAP_NET(MEM|IOV), and it's either there or it's not. If you're thinking about advertising the support all the way to the user, I'm not sure if page pool is the right place to do so. It's more of a queue property. BTW, Mina, the core should probably also check that XDP isn't installed before / while the netmem is bound to a queue.