From: Yunsheng Lin <linyunsheng@huawei.com>
To: Florian Fainelli <florian.fainelli@broadcom.com>,
<davem@davemloft.net>, <kuba@kernel.org>, <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Alexander Duyck <alexanderduyck@fb.com>
Subject: Re: [PATCH net-next v23 3/7] mm: page_frag: use initial zero offset for page_frag_alloc_align()
Date: Fri, 24 Jan 2025 17:52:33 +0800 [thread overview]
Message-ID: <ead00fb7-8538-45b3-8322-8a41386e7381@huawei.com> (raw)
In-Reply-To: <2ef8b7d4-7fae-4a08-9db1-4a33cd56ec9c@broadcom.com>
On 2025/1/24 3:15, Florian Fainelli wrote:
>
> Sorry for the late feedback, this patch causes the bgmac driver in is .ndo_open() function to return -ENOMEM, the call trace looks like this:
Hi, Florian
Thanks for the report.
>
> bgmac_open
> -> bgmac_dma_init
> -> bgmac_dma_rx_skb_for_slot
> -> netdev_alloc_frag
>
> BGMAC_RX_ALLOC_SIZE = 10048 and PAGE_FRAG_CACHE_MAX_SIZE = 32768.
I guess BGMAC_RX_ALLOC_SIZE being bigger than PAGE_SIZE is the
problem here, as the frag API is not really supporting allocating
fragment that is bigger than PAGE_SIZE, as it will fall back to
allocate the base page when order-3 compound page allocation fails,
see __page_frag_cache_refill().
Also, it seems strange that bgmac driver seems to always use jumbo
frame size to allocate fragment, isn't more appropriate to allocate
the fragment according to MTU?
>
> Eventually we land into __page_frag_alloc_align() with the following parameters across multiple successive calls:
>
> __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=0
> __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=10048
> __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=20096
> __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=30144
>
> So in that case we do indeed have offset + fragsz (40192) > size (32768) and so we would eventually return NULL.
It seems the changing of '(unlikely(offset < 0))' checking to
"fragsz > PAGE_SIZE" causes bgmac driver to break more easily
here. But bgmac driver might likely break too if the system
memory is severely fragmented when falling back to alllocate
base page before this patch.
>
> Any idea on how to best fix that within the bgmac driver?
Maybe use the page allocator API directly when allocating fragment
with BGMAC_RX_ALLOC_SIZE > PAGE_SIZE for a quick fix.
In the long term, maybe it makes sense to use the page_pool API
as more drivers are converting to use page_pool API already.
next prev parent reply other threads:[~2025-01-24 9:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 11:53 [PATCH net-next v23 0/7] Replace page_frag with page_frag_cache (Part-1) Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 1/7] mm: page_frag: add a test module for page_frag Yunsheng Lin
2024-11-14 16:02 ` Mark Brown
2024-11-15 9:03 ` Yunsheng Lin
2024-11-15 14:12 ` Mark Brown
2024-11-15 22:34 ` Jakub Kicinski
2024-11-16 5:08 ` Yunsheng Lin
2024-11-16 4:59 ` Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 2/7] mm: move the page fragment allocator from page_alloc into its own file Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 3/7] mm: page_frag: use initial zero offset for page_frag_alloc_align() Yunsheng Lin
2025-01-23 19:15 ` Florian Fainelli
2025-01-24 9:52 ` Yunsheng Lin [this message]
2025-01-24 18:55 ` Florian Fainelli
2024-10-28 11:53 ` [PATCH net-next v23 4/7] mm: page_frag: avoid caller accessing 'page_frag_cache' directly Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 5/7] xtensa: remove the get_order() implementation Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 6/7] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc' Yunsheng Lin
2024-10-28 11:53 ` [PATCH net-next v23 7/7] mm: page_frag: use __alloc_pages() to replace alloc_pages_node() Yunsheng Lin
2024-10-28 15:30 ` [PATCH net-next v23 0/7] Replace page_frag with page_frag_cache (Part-1) Alexander Duyck
2024-10-29 9:36 ` Yunsheng Lin
2024-10-29 15:45 ` Alexander Duyck
2024-11-05 23:57 ` Jakub Kicinski
2024-11-08 0:02 ` Alexander Duyck
2024-11-11 22:20 ` 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=ead00fb7-8538-45b3-8322-8a41386e7381@huawei.com \
--to=linyunsheng@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=alexanderduyck@fb.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®