All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yunsheng Lin <linyunsheng@huawei.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: <davem@davemloft.net>, <kuba@kernel.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linuxarm@openeuler.org>, <hawk@kernel.org>,
	<jonathan.lemon@gmail.com>, <alobakin@pm.me>,
	<willemb@google.com>, <cong.wang@bytedance.com>,
	<pabeni@redhat.com>, <haokexin@gmail.com>, <nogikh@google.com>,
	<elver@google.com>, <memxor@gmail.com>, <edumazet@google.com>,
	<alexander.duyck@gmail.com>, <dsahern@gmail.com>
Subject: Re: [PATCH net-next 3/7] pool_pool: avoid calling compound_head() for skb frag page
Date: Thu, 23 Sep 2021 19:24:24 +0800	[thread overview]
Message-ID: <b2779d81-4cb3-5ccc-8e36-02cd633383f3@huawei.com> (raw)
In-Reply-To: <YUw78q4IrfR0D2/J@apalos.home>

On 2021/9/23 16:33, Ilias Apalodimas wrote:
> On Wed, Sep 22, 2021 at 05:41:27PM +0800, Yunsheng Lin wrote:
>> As the pp page for a skb frag is always a head page, so make
>> sure skb_pp_recycle() passes a head page to avoid calling
>> compound_head() for skb frag page case.
> 
> Doesn't that rely on the driver mostly (i.e what's passed in skb_frag_set_page() ? 
> None of the current netstack code assumes bv_page is the head page of a 
> compound page.  Since our page_pool allocator can will allocate compound
> pages for order > 0,  why should we rely on it ?

As the page pool alloc function return 'struct page *' to the caller, which
is the head page of a compound pages for order > 0, so I assume the caller
will pass that to skb_frag_set_page().

For non-pp page, I assume it is ok whether the page is a head page or tail
page, as the pp_magic for both of them are not set with PP_SIGNATURE.

Or should we play safe here, and do the trick as skb_free_head() does in
patch 6?

> 
> Thanks
> /Ilias
>>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>>  include/linux/skbuff.h | 2 +-
>>  net/core/page_pool.c   | 2 --
>>  2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 6bdb0db3e825..35eebc2310a5 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -4722,7 +4722,7 @@ static inline bool skb_pp_recycle(struct sk_buff *skb, void *data)
>>  {
>>  	if (!IS_ENABLED(CONFIG_PAGE_POOL) || !skb->pp_recycle)
>>  		return false;
>> -	return page_pool_return_skb_page(virt_to_page(data));
>> +	return page_pool_return_skb_page(virt_to_head_page(data));
>>  }
>>  
>>  #endif	/* __KERNEL__ */
>> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
>> index f7e71dcb6a2e..357fb53343a0 100644
>> --- a/net/core/page_pool.c
>> +++ b/net/core/page_pool.c
>> @@ -742,8 +742,6 @@ bool page_pool_return_skb_page(struct page *page)
>>  {
>>  	struct page_pool *pp;
>>  
>> -	page = compound_head(page);
>> -
>>  	/* page->pp_magic is OR'ed with PP_SIGNATURE after the allocation
>>  	 * in order to preserve any existing bits, such as bit 0 for the
>>  	 * head page of compound page and bit 1 for pfmemalloc page, so
>> -- 
>> 2.33.0
>>
> .
> 

  reply	other threads:[~2021-09-23 11:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22  9:41 [PATCH net-next 0/7] some optimization for page pool Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 1/7] page_pool: disable dma mapping support for 32-bit arch with 64-bit DMA Yunsheng Lin
2021-09-23  9:10   ` Ilias Apalodimas
2021-09-23  9:33   ` Jesper Dangaard Brouer
2021-09-23 10:02     ` Ilias Apalodimas
2021-09-23 11:13       ` Yunsheng Lin
2021-09-23 13:07         ` Ilias Apalodimas
2021-09-24  7:04           ` Yunsheng Lin
2021-09-24  7:25             ` Ilias Apalodimas
2021-09-24  8:01               ` Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 2/7] page_pool: support non-split page with PP_FLAG_PAGE_FRAG Yunsheng Lin
2021-09-23 12:08   ` Jesper Dangaard Brouer
2021-09-24  7:23     ` Yunsheng Lin
2021-09-30  7:28       ` [Linuxarm] " Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 3/7] pool_pool: avoid calling compound_head() for skb frag page Yunsheng Lin
2021-09-23  8:33   ` Ilias Apalodimas
2021-09-23 11:24     ` Yunsheng Lin [this message]
2021-09-23 11:47       ` Ilias Apalodimas
2021-09-24  7:33         ` Yunsheng Lin
2021-09-24  7:44           ` Ilias Apalodimas
2021-09-22  9:41 ` [PATCH net-next 4/7] page_pool: change BIAS_MAX to support incrementing Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 5/7] skbuff: keep track of pp page when __skb_frag_ref() is called Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 6/7] skbuff: only use pp_magic identifier for a skb' head page Yunsheng Lin
2021-09-22  9:41 ` [PATCH net-next 7/7] skbuff: remove unused skb->pp_recycle Yunsheng Lin
2021-09-23  7:07 ` [PATCH net-next 0/7] some optimization for page pool Ilias Apalodimas
2021-09-23 11:12   ` 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=b2779d81-4cb3-5ccc-8e36-02cd633383f3@huawei.com \
    --to=linyunsheng@huawei.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alobakin@pm.me \
    --cc=cong.wang@bytedance.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=haokexin@gmail.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=memxor@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nogikh@google.com \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.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.