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 25DE4E7543E for ; Tue, 3 Oct 2023 09:40:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEA16940009; Tue, 3 Oct 2023 05:40:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A734B8D0003; Tue, 3 Oct 2023 05:40:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 913A9940009; Tue, 3 Oct 2023 05:40:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7B37B8D0003 for ; Tue, 3 Oct 2023 05:40:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3DE73160222 for ; Tue, 3 Oct 2023 09:40:54 +0000 (UTC) X-FDA: 81303656028.19.AA00F39 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf08.hostedemail.com (Postfix) with ESMTP id 72D3F160005 for ; Tue, 3 Oct 2023 09:40:51 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=XGbiJdiD; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf08.hostedemail.com: domain of ilias.apalodimas@linaro.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=ilias.apalodimas@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696326051; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6GYoLfhpjKn+Ov/B91dyx3sCIeGji5aj/3JFe9K4TQ8=; b=ETxFANnZ5Nls7dm9TyUjsDcEumrAvUsUQF6Im00x/gZ38ejvuProVuBtp5pfFPTVZwexIl B9P0rfSkLFS6RT03a9/TpV/fbJVrF1n749KoZjBe0JIXbxawd647XSAUcUDfGY/5vlIGFF IE58f/xI2g7D8bHSF+8rD/V2tIdFprE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=XGbiJdiD; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf08.hostedemail.com: domain of ilias.apalodimas@linaro.org designates 209.85.167.42 as permitted sender) smtp.mailfrom=ilias.apalodimas@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696326051; a=rsa-sha256; cv=none; b=rTz3eqrHvp4VRqd0dPJ9oEuhg9uWMa+3GdFPubzWd+Z3IQI5qSNW0J89pp90sGENyuL3Tu xmNhvD9XyPMuJGQVkNKfe9vl632k4K8UOQKQa1+VLTo/PUOvXfKz/AfG77PWAcUvZo5Kd3 BqQP/XZ23rfcNXPRVAtR4UMqNtYoT0Y= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-504427aae4fso4996500e87.1 for ; Tue, 03 Oct 2023 02:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696326049; x=1696930849; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6GYoLfhpjKn+Ov/B91dyx3sCIeGji5aj/3JFe9K4TQ8=; b=XGbiJdiD3tGm5CuC8G9UptXwHw2LR8dnTzcV9WTDpEtMiNMBj0uhIjcdtWu9CAF2PN PjYC3XHXbRyztEfvYqrzijNpFDB1UeUhnoQlQ3Z8D8ozV7UR0eHBV4rbPFrEKpBhVC+6 Slg94B1l4MDomB/r0FfJ9cSJgFz/DBl1EKweBbrGu1dYcs/f6qgQzpxqHXbSzyoCBWjG SiIgWNHzyCgMvJ55bs4mTcjsj/eqJ7A/LGRWEzcd3GysnOE0k39IV9ov/b2KaFcPLb90 /6PE8d9DUoDRQQWp9VPNodJILaVSrw3zk21gF0BxHI1UJuYzAj1cbm4zoPJaoV5iIHDu yo0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696326049; x=1696930849; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6GYoLfhpjKn+Ov/B91dyx3sCIeGji5aj/3JFe9K4TQ8=; b=lgf5/c9jKCWpxDlsM6Wy4mctSuz+mTU/WXHKLdVK+b/5UQscAIpf8tSGYaonqCKybn OU46vu3/wrvNk15+O5rQHChiQqfZq9OlxN4QWVaZlIvKE6C0NAP84tUi/ZC28UUMaf9q baQUerInJgWvJkWztPHwlN1CytzGww3ye6rJMghxhY7et+I4VzAk2xJ3uwFqAXaBGHOG HwzY0cePKk+C/IOihQ7OD9bweAtaW4eiKQ14tIqk9tBCPLdnHgu1EXgyd0u2fcthoUiO GeL7yWDXGsMilfbCn2SRLEeqOJ5W7a2UwGW5GAp6Ozv9Z/B+DYRDnKrf19Pfs1BASTQ9 Y66Q== X-Gm-Message-State: AOJu0YwpcH5XYUYp/fR0EiCIpaOiY9hisuppUtQthpfWm1uOU2IjqFBp jKkxjDX2q1EdjeLBUxfbDX47XOu/KboeUCidiUq5TA== X-Google-Smtp-Source: AGHT+IFVyhekx4L71P1JPgGuvXrNSgm3tOdnKfCtOCBbpMtiRW1FJxuAE6TseQq+oIs+ZMNtbFTAdDqEYrMsAKVXtYo= X-Received: by 2002:a05:6512:3d04:b0:500:7aba:4d07 with SMTP id d4-20020a0565123d0400b005007aba4d07mr2044702lfv.22.1696326049577; Tue, 03 Oct 2023 02:40:49 -0700 (PDT) MIME-Version: 1.0 References: <20230922091138.18014-1-linyunsheng@huawei.com> <20230922091138.18014-2-linyunsheng@huawei.com> In-Reply-To: From: Ilias Apalodimas Date: Tue, 3 Oct 2023 12:40:13 +0300 Message-ID: Subject: Re: [PATCH net-next v10 1/6] page_pool: fragment API support for 32-bit arch with 64-bit DMA To: Paolo Abeni Cc: Yunsheng Lin , davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Alexander Duyck , Liang Chen , Alexander Lobakin , Guillaume Tucker , Matthew Wilcox , Linux-MM , Jesper Dangaard Brouer , Eric Dumazet Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 72D3F160005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 7oz496o3mda8uyixszgppbqskr8dn6y8 X-HE-Tag: 1696326051-824380 X-HE-Meta: U2FsdGVkX1+fmWudrcINA0Hh7lN8jRWDnkgtHAgr174WP6rldufKd6VAn1+6xvlU6GIcGRAjvjR9lh24NiytNAgs74AT/6URCOUf4j4I62ZgeanoMT0emZHWIJp8UwBNPf9gMq0k6WpoNeSuaZ7AvEju2nwZ0hZFqYfLkQ842XSM5sOOgxsBjKwauk2v/xpu6t0hA5N5NvavRk+c+3FDG11QsyBptCzIZ8nX/m75zbqhXCxA7eZKl7EcD3V/lbNkw51ZVOFcQ/MfUn9Q/CNXizfV/9GaXfjIx2nRnPQ0G9oKpwwY9xdmwR0roGltWB+yXOsE0FSFonqjdUVCJGlZOOg1S8xCLyn01OZzxgyi7WfKIY7OnXLfeMh346Fw2vjd3PJ4sBr1I09t7xKTcIR+xf3HEzPb8JooBLJcndSuj8ZQuP2YzhV0/G6wUilbbgnkghxouLRdjnqYZsVnBCwTFnwSNNKCqpwLNdnS/xobDRuFKOJxQJY9C7WxYJKD09n//Fl0G1sUqYu6ENdoS5rnsg5PFfpPtJhJ8YThvxVadX8mzIMg+niGtU3x3ewGwDcmEmyi44lHkS1xo9BuRteVylF8YoEzTCZtNvA4VPYOv8aej6aTx+B6Dst3Rj2QziiOwdnpUymMGmjpjs/m4X87N+i3mjU/Iii0sWtpUYNsInR0AveRuuBoax158gbmuG1n1QdEwX+U11iA6p6OtX2yy+PL8AgAikHofv0c8evnmFquKLIbEr5RIH7w93QZDCPuIbpCDXI6gGKpaJ9UooEApMhtdQjuUv18fwJUVvlP97LAeBP98XgA1kSrxYltO8zwHAFF+p0o3Hy4U9iPjeqRHWyBm3vcalP55OJdcCEZj72sH+dsDSlgAH1QY+50MwlHECW3fWNAeXnbkMqiMvWek8E/0ci8uXxSunxma3mz46POD1xCFBXrqQwIgRZqqW0UMVFU94mfdd8xGbuCBvi MZJS6wQ2 U7ZnM35/uqbXAa7kGuXBK8eCCdqBd+jcV4Ep40Qb7ebqGBa0oRv8p6cddnr58VLo4gNs4WHw1UCJDF5ezj2A9ZWgF/EYrg2gDkqhzY8GMhtsC5cdvYMbpqS7w8kXACVBqTWq929oW1yXp/qn+3mW4EE8QB5G1rJkvb2tAdgpLoo/WNKNVVYWuqlks0T+nT2ThnhDF8tDszAqQEGUZKknoja+KLm+xXgwEmvZhnn/WGOJCbkrTjrWLlHG/w1RMgCwOBUm9tmX6do13honJNACtGOGeXipTSY9NuYVy4FVdR8HMu5zL5eRdgoTJKTT9hrCbxvdYXAAN7qIuSA0pzp1UWP05R6jCIIFvj8i4s/u4LVEjS6dL3uJz9b89x7ZTy1dmFTnZa6jiayYLNv/bd+W8kMv8gtKwDZezeb+wpTNzL6lPt/Wc41TUTsrixj37LFKgyZKqUmhtA8QXnmxmCC50baH46aU+AMM9IuFIB+0N1w8dYH2JU+cTnbdmEX096MXcfRMBQMRck9oK1R1P+JMhpoyLWFSlJ9v59mUzQ4gxEvartogONqfi/p40cQNmFjaNF3gMTS5uH3KaoOy4vtuH8/tEy+/T+zRVylJdjk3gfjdszwIs29P8hnysAIsR9eOEuZ8MnkSmKVtja7m4yxP+FQ+70EA2sL3sfrZk9duQVJrtPdQ= 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: Hi Paolo On Tue, 3 Oct 2023 at 10:46, Paolo Abeni wrote: > > On Fri, 2023-09-22 at 17:11 +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. > > > > 1. https://lore.kernel.org/all/20211117075652.58299-1-linyunsheng@huawei.com/ > > 2. https://lore.kernel.org/all/20230818145145.4b357c89@kernel.org/ > > > > Signed-off-by: Jakub Kicinski > > Signed-off-by: Yunsheng Lin > > CC: Lorenzo Bianconi > > CC: Alexander Duyck > > CC: Liang Chen > > CC: Alexander Lobakin > > CC: Guillaume Tucker > > CC: Matthew Wilcox > > CC: Linux-MM > > --- > > include/linux/mm_types.h | 13 +------------ > > include/net/page_pool/helpers.h | 20 ++++++++++++++------ > > net/core/page_pool.c | 14 +++++++++----- > > 3 files changed, 24 insertions(+), 23 deletions(-) > > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > index 36c5b43999e6..74b49c4c7a52 100644 > > --- a/include/linux/mm_types.h > > +++ b/include/linux/mm_types.h > > @@ -125,18 +125,7 @@ struct page { > > struct page_pool *pp; > > unsigned long _pp_mapping_pad; > > unsigned long dma_addr; > > - union { > > - /** > > - * dma_addr_upper: might require a 64-bit > > - * value on 32-bit architectures. > > - */ > > - unsigned long dma_addr_upper; > > - /** > > - * For frag page support, not supported in > > - * 32-bit architectures with 64-bit DMA. > > - */ > > - atomic_long_t pp_frag_count; > > - }; > > + atomic_long_t pp_frag_count; > > }; > > struct { /* Tail pages of compound page */ > > unsigned long compound_head; /* Bit zero is set */ > > As noted by Jesper, since this is touching the super-critcal struct > page, an explicit ack from the mm people is required. > > @Matthew: could you please have a look? > > I think it would be nice also an explicit ack from Jesper and/or Ilias. I am trying! Unfortunately, it's this time of the year when I have to travel a lot. I'll be back in 15 days from now and I will be able to have a look Thanks and sorry for the delay /Ilias > > Cheers, > > Paolo >