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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC58FC678DC for ; Thu, 17 Aug 2023 23:58:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356195AbjHQX57 (ORCPT ); Thu, 17 Aug 2023 19:57:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356185AbjHQX5r (ORCPT ); Thu, 17 Aug 2023 19:57:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D8FB35B6 for ; Thu, 17 Aug 2023 16:57:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 041026305E for ; Thu, 17 Aug 2023 23:57:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6ECEC433C8; Thu, 17 Aug 2023 23:57:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692316665; bh=btl0dkNCYRkk/1TT90aCWzNZIQZBgF8kNpBWP+Xu7GU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jrNJOjBgxx9PeDzYdlK571nLgVv3D0Z9BSLyJtr6Eh5cnIixPqVpOG+yayReHylfs ZzDGKdaNKXCUt6/GW/HmmnBoBzLrhSKo+alBPCUeriEdroG7cdAd0dNU4Us8P96Lzk ds3xLeGELqgo1L+nX4FyOOnm0O6uda4HxK8tW5mjbZHhdSA8t2EQ8W1cBJ11YelnQV OcEgu+9wz+KE5ij1/4vrWBfIcee4NmpTyhMZKK+6osOMv0Yn8EQKXqn8IVGuhj80xL 1Y46mh3jdbJqj27s0vbLR4kHvY4lZo65Oeq7UXOY4KBg2l72MhqbBbFltvCnDjLswe fploWqyF05hfw== Date: Thu, 17 Aug 2023 16:57:44 -0700 From: Jakub Kicinski To: Ilias Apalodimas Cc: Mina Almasry , Yunsheng Lin , davem@davemloft.net, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Alexander Duyck , Liang Chen , Alexander Lobakin , Saeed Mahameed , Leon Romanovsky , Eric Dumazet , Jesper Dangaard Brouer Subject: Re: [PATCH net-next v7 1/6] page_pool: frag API support for 32-bit arch with 64-bit DMA Message-ID: <20230817165744.73d61fb6@kernel.org> In-Reply-To: References: <20230816100113.41034-1-linyunsheng@huawei.com> <20230816100113.41034-2-linyunsheng@huawei.com> <20230817091554.31bb3600@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 Aug 2023 19:59:37 +0300 Ilias Apalodimas wrote: > > Can we assume the DMA mapping of page pool is page aligned? We should > > be, right? > > Yes > > > That means we're storing 12 bits of 0 at the lower end. > > So even with 32b of space we can easily store addresses for 32b+12b => > > 16TB of memory. "Ought to be enough" to paraphrase Bill G, and the > > problem is only in our heads? > > Do you mean moving the pp_frag_count there? Right, IIUC we don't have enough space to fit dma_addr_t and the refcount, but if we store the dma addr on a shifted u32 instead of using dma_addr_t explicitly - the refcount should fit? > I was questioning the need to have PP_FLAG_PAGE_SPLIT_IN_DRIVER > overall. With Yunshengs patches such a platform would allocate a > page, so why should we prevent it from splitting it internally? Splitting it is fine, the problem is that the refcount AKA page->pp_frag_count** counts outstanding PP-aware references and page->refcount counts PP-unaware references. If we want to use page->refcount directly we'd need to unmap the page whenever drivers calls page_pool_defrag_page(). But the driver may assume the page is still mapped afterwards. We can change the API to make this behavior explicit. Although IMHO that's putting the burden of rare platforms on non-rare platforms which we should avoid. ** I said it before and I will keep saying this until someone gets angry at me - I really think we should rename this field because the association with frags is a coincidence.