All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Liang Chen <liangchen.linux@gmail.com>
Cc: ilias.apalodimas@linaro.org, hawk@kernel.org,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	linyunsheng@huawei.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] skbuff: Optimize SKB coalescing for page pool case
Date: Fri, 30 Jun 2023 16:07:09 -0700	[thread overview]
Message-ID: <20230630160709.45ea4faa@kernel.org> (raw)
In-Reply-To: <20230628121150.47778-1-liangchen.linux@gmail.com>

On Wed, 28 Jun 2023 20:11:50 +0800 Liang Chen wrote:
> +static inline void page_pool_page_ref(struct page *page)
> +{
> +	struct page *head_page = compound_head(page);
> +
> +	if (page_pool_is_pp_page(head_page) &&
> +			page_pool_is_pp_page_frag(head_page))
> +		atomic_long_inc(&head_page->pp_frag_count);
> +	else
> +		get_page(head_page);

AFAICT this is not correct, you cannot take an extra *pp* reference 
on a pp page, unless it is a frag. If the @to skb is a pp skb (and it
must be, if we get here) we will have two skbs with pp_recycle = 1.
Which means if they both get freed at the same time they will both
try to return / release the page.

I haven't looked at Yunsheng's v5 yet, but that's why I was asking 
to rename the pp_frag_count to pp_ref_count. pp_frag_count is a true
refcount (rather than skb->pp_recycle acting as a poor man's single
shot refcount), so in case of frag'd pages / after Yunsheng's work
we will be able to take new refs.

Long story short please wait until Yunsheng's changes are finalized.

  parent reply	other threads:[~2023-06-30 23:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 12:11 [PATCH net-next] skbuff: Optimize SKB coalescing for page pool case Liang Chen
2023-06-29  6:53 ` Yunsheng Lin
2023-06-29 12:17   ` Liang Chen
2023-06-29 12:19     ` Liang Chen
2023-06-30 11:52       ` Yunsheng Lin
2023-07-03  9:09         ` Liang Chen
2023-06-30 23:07 ` Jakub Kicinski [this message]
2023-07-03  9:12   ` Liang Chen
2023-07-03 18:53     ` Jakub Kicinski
2023-07-04  0:50       ` Yunsheng Lin
2023-07-04  4:54         ` Liang Chen

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=20230630160709.45ea4faa@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=liangchen.linux@gmail.com \
    --cc=linyunsheng@huawei.com \
    --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.