Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1355064rwd; Tue, 13 Jun 2023 08:06:50 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ppkSFHpf+qhmMe039wx62OiaEpEk6UHFCyzvONPxnlUVKaeznqSub9S4nsNVwXTHYuW3i X-Received: by 2002:a17:907:2d22:b0:978:b94e:83dd with SMTP id gs34-20020a1709072d2200b00978b94e83ddmr13798918ejc.75.1686668810025; Tue, 13 Jun 2023 08:06:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686668810; cv=none; d=google.com; s=arc-20160816; b=L7gdK5bsusnDGGz5HqIOj/NAaVi4iZg+113RhosO4U74/n6uHJ/erRJQn7upDo6jGd XQMgVzdlP+IUxKvE0uhP3qpHb/b1aamvT73N5V9pCootFoMsmOcRtHRxJVelohmCwb5K 6tgNINoXwVK26py3MSf08RkHEnHpNWqqUTTmBa+kHRnkuaLQ7NkhFTRxTZXp2WRtoLpC zjAe/+DjFUfLwU6IjoUsOglz69PI14XXnY2IObwzPNJKTTkEBB3DilXsFtn+VR6KHNDy SuhXV6N4zB4iOo10MkqGeezF+VeXq1iga76xtvjCMqGFmPySbA7xc6ts0zHqNV/fh6un uwSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=PLlWFUrferj4g53iCG/BqiTgqM0UBmr45zNNhlToYsg=; b=fgFAxbBuHhMFwV45ULFt6NKxlzBqc3Web3FHsoCJg/OKXZ/BztOcM6cJYwgsacLsne XvpuOLCWX1GCNZsSnQYbAyyiBAhriXxb0EdJTbA9WGlahdT6gBA5puHg6FD/onlh7klJ W19353MjyAkGcMGqAHDVUsHpE7dOu+aIxFr7BFmRL4hYba1dP7Zlde38PtxxFi0g2thA iT62VOtl2o2N2m0EfmIykrw2Q6m3yPIbVvCteKEb4nEswlBYRw5cJhex7qnhl6/B7bzR mdM5pt2o91mQo84h9jrzlBcYKArPjiVuMdyaD6mqFkul9k+SxrVlf3KX9XsS/nQ5tUmS SBSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=sHHJ811W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qx25-20020a170906fcd900b00978ac4d7dcesi7231109ejb.528.2023.06.13.08.06.15; Tue, 13 Jun 2023 08:06:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=sHHJ811W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242596AbjFMOhB (ORCPT + 99 others); Tue, 13 Jun 2023 10:37:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234939AbjFMOhA (ORCPT ); Tue, 13 Jun 2023 10:37:00 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52062189; Tue, 13 Jun 2023 07:36:58 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-66577752f05so1858835b3a.0; Tue, 13 Jun 2023 07:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686667017; x=1689259017; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PLlWFUrferj4g53iCG/BqiTgqM0UBmr45zNNhlToYsg=; b=sHHJ811WGZ0/KTLmPkqZTw5cwc+f5LM8YHBQMbgtDmanyn/amD0IFUH92FzMNGAXkC 2XrjrXgN7rcDF05BXRObHVuCs8qiVLxe3Yh4t0nQlSibV3ZTN0FjAB3Sa7SEiJzKwiiR Q1kWNxNO3SXOCZ3b6xG/EiiuBsaxbnQVs7P/q/Pgugxx2eTJ7Z/BCWVp8WABZ61VFPD6 QLT0amN7kPrcmyEZFDQcA0yULahj0reoNJQaXPvefaFDMBB5Wu4sNnnUIrDtoryyP3oK fFWkqiYla1FhB0vWv4TO5b2QHEEQ7l4ZrujV+JZk8ms7AaRMFDJSIXOybVHJQOsNoG42 6yeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686667017; x=1689259017; h=content-transfer-encoding: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=PLlWFUrferj4g53iCG/BqiTgqM0UBmr45zNNhlToYsg=; b=OMBiafQ7vfsNgoCRMAcC756zrLltI6obkE86GH1H/sxri34a2aiQOrm8nU299c3ITu Zxx1D0TTq3jjj7YF5N4KmwQU5il/9CPoFU8p/epD10znPgGM76nsruhSoPPlaeBerEvD xziwmZk66Qi11a/IT29MSbDaWGBHynGz8yuGEcxBr6vQkV5Y4CFJWuCz7T7LncPo/ttg 3WQS5//QzPJ542NmGxwmW4WLH6g/X+8zRq4vp5wO2tCSy/xWrfLblnZ7Qnj4wAyYdRmE 8PRtdo8xkTH0ppARtWVxFatrWorWztVazux2K3wf3rGXJ0cqx/D8+CkpHfWqT4lVlvxS WFJA== X-Gm-Message-State: AC+VfDwT52E4F2qChy2/NdsXa88CykNbz3LRA+ZF3FWvzUSwT3iAeUUE 0DkyHlMhP6t1RhdUdkkmVy+bmLmK4FTZ3TYwTfc= X-Received: by 2002:a17:90b:3a86:b0:259:bdb:6956 with SMTP id om6-20020a17090b3a8600b002590bdb6956mr10601398pjb.7.1686667017272; Tue, 13 Jun 2023 07:36:57 -0700 (PDT) MIME-Version: 1.0 References: <20230609131740.7496-1-linyunsheng@huawei.com> <20230609131740.7496-4-linyunsheng@huawei.com> In-Reply-To: <20230609131740.7496-4-linyunsheng@huawei.com> From: Alexander Duyck Date: Tue, 13 Jun 2023 07:36:20 -0700 Message-ID: Subject: Re: [PATCH net-next v3 3/4] page_pool: introduce page_pool_alloc() API To: Yunsheng Lin Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Bianconi , Jesper Dangaard Brouer , Ilias Apalodimas , Eric Dumazet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 9, 2023 at 6:20=E2=80=AFAM Yunsheng Lin wrote: > > Currently page pool supports the below use cases: > use case 1: allocate page without page splitting using > page_pool_alloc_pages() API if the driver knows > that the memory it need is always bigger than > half of the page allocated from page pool. > use case 2: allocate page frag with page splitting using > page_pool_alloc_frag() API if the driver knows > that the memory it need is always smaller than > or equal to the half of the page allocated from > page pool. > > There is emerging use case [1] & [2] that is a mix of the > above two case: the driver doesn't know the size of memory it > need beforehand, so the driver may use something like below to > allocate memory with least memory utilization and performance > penalty: > > if (size << 1 > max_size) > page =3D page_pool_alloc_pages(); > else > page =3D page_pool_alloc_frag(); > > To avoid the driver doing something like above, add the > page_pool_alloc() API to support the above use case, and update > the true size of memory that is acctually allocated by updating > '*size' back to the driver in order to avoid the truesize > underestimate problem. > > 1. https://lore.kernel.org/all/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1= 683896626.git.lorenzo@kernel.org/ > 2. https://lore.kernel.org/all/20230526054621.18371-3-liangchen.linux@gma= il.com/ > > Signed-off-by: Yunsheng Lin > CC: Lorenzo Bianconi > CC: Alexander Duyck > --- > include/net/page_pool.h | 43 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/include/net/page_pool.h b/include/net/page_pool.h > index 0b8cd2acc1d7..c135cd157cea 100644 > --- a/include/net/page_pool.h > +++ b/include/net/page_pool.h > @@ -260,6 +260,49 @@ static inline struct page *page_pool_dev_alloc_frag(= struct page_pool *pool, > return page_pool_alloc_frag(pool, offset, size, gfp); > } > > +static inline struct page *page_pool_alloc(struct page_pool *pool, > + unsigned int *offset, > + unsigned int *size, gfp_t gfp) > +{ > + unsigned int max_size =3D PAGE_SIZE << pool->p.order; > + struct page *page; > + > + *size =3D ALIGN(*size, dma_get_cache_alignment()); > + > + if (WARN_ON(*size > max_size)) > + return NULL; > + > + if ((*size << 1) > max_size || PAGE_POOL_DMA_USE_PP_FRAG_COUNT) { > + *size =3D max_size; > + *offset =3D 0; > + return page_pool_alloc_pages(pool, gfp); > + } > + > + page =3D __page_pool_alloc_frag(pool, offset, *size, gfp); > + if (unlikely(!page)) > + return NULL; > + > + /* There is very likely not enough space for another frag, so app= end the > + * remaining size to the current frag to avoid truesize underesti= mate > + * problem. > + */ > + if (pool->frag_offset + *size > max_size) { > + *size =3D max_size - *offset; > + pool->frag_offset =3D max_size; > + } > + Rather than preventing a truesize underestimation this will cause one. You are adding memory to the size of the page reserved and not accounting for it anywhere as this isn't reported up to the network stack. I would suggest dropping this from your patch. > + return page; > +} > + > +static inline struct page *page_pool_dev_alloc(struct page_pool *pool, > + unsigned int *offset, > + unsigned int *size) > +{ > + gfp_t gfp =3D (GFP_ATOMIC | __GFP_NOWARN); > + > + return page_pool_alloc(pool, offset, size, gfp); > +} > + > /* get the stored dma direction. A driver might decide to treat this loc= ally and > * avoid the extra cache line from page_pool to determine the direction > */ > -- > 2.33.0 >