From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Ratheesh Kannoth <rkannoth@marvell.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kuba@kernel.org, pabeni@redhat.cm, edumazet@google.com,
aleksander.lobakin@intel.com, hawk@kernel.org,
sgoutham@marvell.com, gakula@marvell.com, sbhatta@marvell.com,
hkelam@marvell.com
Subject: Re: [PATCH v1 net] octeontx2-pf: fix page_pool creation fail for rings > 32k
Date: Tue, 15 Aug 2023 10:41:52 +0200 [thread overview]
Message-ID: <110797fb-fea6-cb4d-af3c-4665e8246479@kernel.org> (raw)
In-Reply-To: <20230814132411.2475687-1-rkannoth@marvell.com>
On 14/08/2023 15.24, Ratheesh Kannoth wrote:
> octeontx2 driver calls page_pool_create() during driver probe()
> and fails if queue size > 32k. Page pool infra uses these buffers
> as shock absorbers for burst traffic. These pages are pinned
> down as soon as page pool is created.
It isn't true that "pages are pinned down as soon as page pool is created".
We need to improve this commit text.
My suggestion:
These pages are pinned down over time as working sets varies, due to
the recycling nature of page pool, given page pool (currently) don't
have a shrinker mechanism, the pages remain pinned down in ptr_ring.
> As page pool does direct
> recycling way more aggressivelyi, often times ptr_ring is left
^
Typo
(my suggestion already covers recycling)
> unused at all. Instead of clamping page_pool size to 32k at
> most, limit it even more to 2k to avoid wasting memory on much
> less used ptr_ring.
I would adjust and delete "much less used".
I assume you have the octeontx2 hardware available (which I don't).
Can you test that this adjustment to 2k doesn't cause a performance
regression on your hardware?
And then produce a statement in the commit desc like:
This have been tested on octeontx2 hardware (devel board xyz).
TCP and UDP tests using netperf shows not performance regressions.
2K with page_size 4KiB is around 8MiB if PP gets full.
It would be convincing if commit message said e.g. PP pool_size 2k can
maximum pin down 8MiB per RX-queue (assuming page size 4K), but that is
okay as systems using octeontx2 hardware often have many GB of memory.
>
> Fixes: b2e3406a38f0 ("octeontx2-pf: Add support for page pool")
> Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>
> ---
>
> ChangeLogs:
>
> v0->v1: Commit message changes.
> ---
> ---
> drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c | 2 +-
> drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index 77c8f650f7ac..fc8a1220eb39 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> @@ -1432,7 +1432,7 @@ int otx2_pool_init(struct otx2_nic *pfvf, u16 pool_id,
> }
>
> pp_params.flags = PP_FLAG_PAGE_FRAG | PP_FLAG_DMA_MAP;
> - pp_params.pool_size = numptrs;
> + pp_params.pool_size = OTX2_PAGE_POOL_SZ;
> pp_params.nid = NUMA_NO_NODE;
> pp_params.dev = pfvf->dev;
> pp_params.dma_dir = DMA_FROM_DEVICE;
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> index ba8091131ec0..f6fea43617ff 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
> @@ -30,6 +30,8 @@
> #include <rvu_trace.h>
> #include "qos.h"
>
> +#define OTX2_PAGE_POOL_SZ 2048
> +
> /* IPv4 flag more fragment bit */
> #define IPV4_FLAG_MORE 0x20
>
next prev parent reply other threads:[~2023-08-15 8:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 13:24 [PATCH v1 net] octeontx2-pf: fix page_pool creation fail for rings > 32k Ratheesh Kannoth
2023-08-15 8:12 ` Simon Horman
2023-08-16 2:15 ` [EXT] " Ratheesh Kannoth
2023-08-15 8:41 ` Jesper Dangaard Brouer [this message]
2023-08-16 2:14 ` Ratheesh Kannoth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=110797fb-fea6-cb4d-af3c-4665e8246479@kernel.org \
--to=hawk@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=hkelam@marvell.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.cm \
--cc=rkannoth@marvell.com \
--cc=sbhatta@marvell.com \
--cc=sgoutham@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).