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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAF9CCDB465 for ; Tue, 17 Oct 2023 01:31:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4019C8D00E2; Mon, 16 Oct 2023 21:31:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B1AD8D00DE; Mon, 16 Oct 2023 21:31:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A1598D00E2; Mon, 16 Oct 2023 21:31:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1CC118D00DE for ; Mon, 16 Oct 2023 21:31:47 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EC5EA40CCF for ; Tue, 17 Oct 2023 01:31:46 +0000 (UTC) X-FDA: 81353226612.02.D67D7F4 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf03.hostedemail.com (Postfix) with ESMTP id D1EC120016 for ; Tue, 17 Oct 2023 01:31:44 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hWRuXWUw; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of kuba@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kuba@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697506305; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K7OqRqV4uO9mfsNLFlWOFCf1Gi6HLEkwI6QHo5LQO2k=; b=e+yZ3ZLWrLZFfjj3Gkw7Jem+pDB6MpA7ryWGGfAEJtfvN65hHi8VSAo1gyQD7U1Wzaf+sh i9V+LqTaqQcvfjJYRrWIdPEu+Ik8gKJw2mGZocOu2uBQAIZEofz8mGS7M/cJS4y+/ARCZ4 2r1gNgSq8dGPDYQXXd2Zilvgrl18aHQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hWRuXWUw; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of kuba@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kuba@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697506305; a=rsa-sha256; cv=none; b=ZuggSLHhpEw7YPZp9GOOhTOGQXkiYOIW1PktTfcQn8oSD6dA1z642TxSr7hRYXqaoRBsPJ ciXhLnDmtRjx9Hlv3VtZpW1/Tx9pn6glsiMd8Q4nyrDtM+EHrjcciUGc35ZdTPF2ZCnlml HHm621WDAoFR17LBcPZAcuY8qZKs6bM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A1EF0CE1B35; Tue, 17 Oct 2023 01:31:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 236D7C433C8; Tue, 17 Oct 2023 01:31:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697506299; bh=UR60mYADl5EHC1NoZ4GrAkpMSCrV5ZQb/hfA25cXCI8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hWRuXWUwoKb/yom/A7F87AKYH4syC/l67lawzuKkTbxqZmoiVCVa/B0FON5NvEcGb 1mCXphpQRUs/J/qR0vXPq6E/6//hvzzUG52ZwQclfbnSlVj3jO6O1YXT9FXBrP4PQe EImgT2p0map18oRROeMmWTmGOWqNgG4hMl2bATEvipIs8JRFjGMVFsmJEJE6jamAJP zqP0jxpL9TKeyosrdyND0b3O/sePyDxv4tZg08LMSbywgW9JMuYm1cVng7A+9dD+b9 V99yj12zz6JxUcynopuGHEKfTWNhQgSzOTVl13itv1bBAQaCUW3U3sGFhrzH3HZWX2 iGzyxh5daMIVQ== Date: Mon, 16 Oct 2023 18:31:38 -0700 From: Jakub Kicinski To: Yunsheng Lin Cc: , , , , Alexander Lobakin , Lorenzo Bianconi , Alexander Duyck , Liang Chen , Guillaume Tucker , Matthew Wilcox , Linux-MM , Jesper Dangaard Brouer , Ilias Apalodimas , Eric Dumazet Subject: Re: [PATCH net-next v11 1/6] page_pool: fragment API support for 32-bit arch with 64-bit DMA Message-ID: <20231016183138.2c4366a7@kernel.org> In-Reply-To: <20231013064827.61135-2-linyunsheng@huawei.com> References: <20231013064827.61135-1-linyunsheng@huawei.com> <20231013064827.61135-2-linyunsheng@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D1EC120016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: a74c9jmdbwg7s6yx644d3mbh39cxoytc X-HE-Tag: 1697506304-567093 X-HE-Meta: U2FsdGVkX1+NxRA2aNw8DPKUUI9bizNoV6B8Zrt5mTxUcbpwgfekXi1gRA2xB8YPb3kfAMEXhF0m6mbWqy/5MCx+ZKUCLLGxjXyQhDahpNYMj2Xte0SwXtWMOTIRIGZ+CN9MvggzpNRIaM2vjZ50BMKO9fuh+3YX13DAyQidDtvCocufX5N41ZHTnSCfgc4Nej9Jox6hJVNQpDL+/8SqCCa3G1DQKC1VXR4vMDoF6j0iqXeNqUurkyUVH8ldct0dmJJ0VS/+trQj9g3lVMJTMIqzCvlJM1OT8TfqMHfKNvK35hJ3EhMhXCtLcva1i4XiifGzF1mA7I8fubE9EIeUL/vziu/hk86rAtOG3hQ3GdFMAvwkZN7jPqkIOexj23Jf+Z7EdBzqRVJylkDATGSwJAl/RM7uy91HC5u5Zlbo0YJ9zXi19rsu7oDpppcCS0mFZIL5IjGiO0a+0h8QdHTMpJaBKhMKj5hssfsvruccDYon19ScCxp0IN9CS3dlksM6Tjo2zkpothF3HEJfe6z1T44EUg+omRUajHax8/CTE8AGN6/8MN0ECeasxdqMoQonJDZpmelvN2qIAFBOsI3a8kYb2kTneqSOwsn1p7Hv2wJkuYQKYRw2Tqp0IKIHL6kLWAsqUveztuflJkwcsXV0ElY2YifHlYbkKHoF808b2/qwu6LmhflwosWKpYPeBWk8aC7LozRcd51MeAf2S3F7Wh6XmIm/d5Bz7Gj6oqT4ZGJklpcisMJjxJbk3UPkbd8AfmL0FxGymujwxSw/wnLPVQvN4059+mh1trcjF/2vENRRWjRM/7k3ksH+MtN609I8ojlTumr5YvQJFx5u0RiPlmFH1KqlTTxcyruBK9vybxDCU1aSG7CcJuo1SpCDftWLMUrLS7xqSL00IY3SIZFIZnkMEuOrqgv0YcE0NW7cw+jf3PdVuz7loL3fO+B2j3t0HhV7LANvOq7Y/71yExy Fccf1dip RGttSolwAsPAWr2iOr7dmuHEJwS7kfriwVuzmjKzmLEs7VHBbsUbFfIGoPH2MElDPvwnTtn7j0jzIqbkiBmPDeFbpwVNG6+/24749nTwanE3eiSQPoAiSHTmK3l3j11YgpROTb+jwu05tvWm+2bJRrcJytVtLnIr3P0vGbbIuJlFFKCwkfPC7WV5t3rL2xCwY665h0LRhyLjY3hbc97AA9j6nyqOsG0tyIR2OQXBw3k8V9iLBh4T0+oSdTm4Xs9IqvYkwQf7FpyB9s+2eIhQTCaVRabccdcUV1orwm2dFlFE19FEkNUGfhgBCnQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 13 Oct 2023 14:48:21 +0800 Yunsheng Lin wrote: > Currently page_pool_alloc_frag() is not supported in 32-bit > arch with 64-bit DMA because of the overlap issue between > pp_frag_count and dma_addr_upper in 'struct page' for those > arches, which seems to be quite common, see [1], which means > driver may need to handle it when using fragment API. > > It is assumed that the combination of the above arch with an > address space >16TB does not exist, as all those arches have > 64b equivalent, it seems logical to use the 64b version for a > system with a large address space. It is also assumed that dma > address is page aligned when we are dma mapping a page aligned > buffer, see [2]. > > That means we're storing 12 bits of 0 at the lower end for a > dma address, we can reuse those bits for the above arches to > support 32b+12b, which is 16TB of memory. > > If we make a wrong assumption, a warning is emitted so that > user can report to us. Let me apply this one already, I think it should be uncontroversial from review perspective. And the more time it gets in linux-next the better..