From: Jakub Kicinski <kuba@kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
pavan.chebbi@broadcom.com
Subject: Re: [PATCH net-next] eth: bnxt: take page size into account for page pool recycling rings
Date: Thu, 26 Jun 2025 15:40:29 -0700 [thread overview]
Message-ID: <20250626154029.22cd5d2d@kernel.org> (raw)
In-Reply-To: <CACKFLin2y=Y1s3ge8kfdi-qHGfoQr9S3BwOUCSKTCu6q8Y6D1Q@mail.gmail.com>
On Thu, 26 Jun 2025 14:52:17 -0700 Michael Chan wrote:
> > {
> > + const unsigned int agg_size_fac = PAGE_SIZE / BNXT_RX_PAGE_SIZE;
> > + const unsigned int rx_size_fac = PAGE_SIZE / SZ_4K;
> > struct page_pool_params pp = { 0 };
> > struct page_pool *pool;
> >
> > - pp.pool_size = bp->rx_agg_ring_size;
> > + pp.pool_size = bp->rx_agg_ring_size / agg_size_fac;
>
> The bp->rx_agg_ring_size has already taken the system PAGE_SIZE into
> consideration to some extent in bnxt_set_ring_params(). The
> jumbo_factor and agg_factor will be smaller when PAGE_SIZE is larger.
> Will this overcompensate?
My understanding is basically that bnxt_set_ring_params() operates
on BNXT_RX_PAGE_SIZE so it takes care of 4k .. 32k range pretty well.
But for 64k pages we will use 32k buffers, so 2 agg ring entries
per system page. If our heuristic is that we want the same number
of pages on the device ring as in the pp cache we should divide
the cache size by two. Hope that makes sense.
My initial temptation was to say that agg ring is always shown to
the user in 4kB units, regardless of system page. The driver would
divide and multiply the parameter in the ethtool callbacks. Otherwise
even with this patch existing configs for bnxt have to be adjusted
based on system page size :( But I suspect you may have existing users
on systems with 64kB pages, so this would be too risky? WDYT?
next prev parent reply other threads:[~2025-06-26 22:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 16:54 [PATCH net-next] eth: bnxt: take page size into account for page pool recycling rings Jakub Kicinski
2025-06-26 21:52 ` Michael Chan
2025-06-26 22:40 ` Jakub Kicinski [this message]
2025-06-27 6:48 ` Michael Chan
2025-06-27 22:50 ` patchwork-bot+netdevbpf
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=20250626154029.22cd5d2d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.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).