From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Lorenzo Bianconi <lorenzo@kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH net-next 1/2] page_pool: unify frag page and non-frag page handling
Date: Fri, 26 May 2023 18:38:22 +0300 [thread overview]
Message-ID: <ZHDSblXIPvJhuZV5@hera> (raw)
In-Reply-To: <5640bab0-d2f9-50ee-f3e2-eb0f86b144dc@huawei.com>
On Fri, May 26, 2023 at 08:35:24PM +0800, Yunsheng Lin wrote:
> On 2023/5/26 20:03, Ilias Apalodimas wrote:
> > Hi Yunsheng
> >
> > Apologies for not replying to the RFC, I was pretty busy with internal
> > stuff
> >
> > On Fri, May 26, 2023 at 05:26:14PM +0800, Yunsheng Lin wrote:
> >> Currently page_pool_dev_alloc_pages() can not be called
> >> when PP_FLAG_PAGE_FRAG is set, because it does not use
> >> the frag reference counting.
> >>
> >> As we are already doing a optimization by not updating
> >> page->pp_frag_count in page_pool_defrag_page() for the
> >> last frag user, and non-frag page only have one user,
> >> so we utilize that to unify frag page and non-frag page
> >> handling, so that page_pool_dev_alloc_pages() can also
> >> be called with PP_FLAG_PAGE_FRAG set.
> >
> > What happens here is clear. But why do we need this? Do you have a
> > specific use case in mind where a driver will call
> > page_pool_dev_alloc_pages() and the PP_FLAG_PAGE_FRAG will be set?
>
> Actually it is about calling page_pool_alloc_pages() in
> page_pool_alloc_frag() in patch 2, the use case is the
> veth using page frag support. see:
>
> https://patchwork.kernel.org/project/netdevbpf/patch/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1683896626.git.lorenzo@kernel.org/
Ok I missed that patch.
>
> > If that's the case isn't it a better idea to unify the functions entirely?
>
> As about, page_pool_alloc_frag() does seems to be a superset of
> page_pool_alloc_pages() after this patchset as my understanding.
> If the page_pool_alloc_frag() API turns out to be a good API for
> the driver, maybe we can phase out *page_pool_alloc_pages() as
> time goes by?
Looking at patch 2/2 it seems a bit wasteful. At the moment only hns3 uses
fragments and the length of the allocation seems static. But if someone
else chooses to allocate a > 2048 packet why should it allocate a page?
I just think it's a bit confusing since we have a flag on the pool for page
fragments, but then we violate it when it suits us.
Thanks
/Ilias
next prev parent reply other threads:[~2023-05-26 15:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 9:26 [PATCH net-next 0/2] support non-frag page for page_pool_alloc_frag() Yunsheng Lin
2023-05-26 9:26 ` [PATCH net-next 1/2] page_pool: unify frag page and non-frag page handling Yunsheng Lin
2023-05-26 12:03 ` Ilias Apalodimas
2023-05-26 12:35 ` Yunsheng Lin
2023-05-26 15:38 ` Ilias Apalodimas [this message]
2023-05-27 8:18 ` Yunsheng Lin
2023-05-26 9:26 ` [PATCH net-next 2/2] page_pool: support non-frag page for page_pool_alloc_frag() Yunsheng Lin
2023-05-26 15:16 ` Alexander Duyck
2023-05-27 9:51 ` Yunsheng Lin
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=ZHDSblXIPvJhuZV5@hera \
--to=ilias.apalodimas@linaro.org \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.