From: Ido Schimmel <idosch@idosch.org>
To: "Malladi, Meghana" <m-malladi@ti.com>
Cc: rogerq@kernel.org, danishanwar@ti.com, pabeni@redhat.com,
kuba@kernel.org, edumazet@google.com, davem@davemloft.net,
andrew+netdev@lunn.ch, bpf@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
robh@kernel.org, matthias.schiffer@ew.tq-group.com,
dan.carpenter@linaro.org, rdunlap@infradead.org,
diogo.ivo@siemens.com, schnelle@linux.ibm.com,
glaroque@baylibre.com, john.fastabend@gmail.com, hawk@kernel.org,
daniel@iogearbox.net, ast@kernel.org, srk@ti.com,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [EXTERNAL] Re: [PATCH net 1/3] net: ti: icssg-prueth: Use page_pool API for RX buffer allocation
Date: Wed, 5 Feb 2025 19:41:00 +0200 [thread overview]
Message-ID: <Z6OirBmdSLuY5YkI@shredder> (raw)
In-Reply-To: <9287a623-5663-4705-b61a-3ab5f5cb2424@ti.com>
On Tue, Feb 04, 2025 at 11:25:02PM +0530, Malladi, Meghana wrote:
> Seems like none of the pages which have been allocated aren't getting
> recycled in the rx path after being used unless its some error case. Will
> try to fix this.
skb_mark_for_recycle() should help with page recycling when an skb that
uses them is freed.
Anyway, I believe that I don't see put call when tearing down the Rx
ring because prueth_rx_cleanup() is using page_pool_recycle_direct()
when it shouldn't. AFAICT, prueth_rx_cleanup() is only called from the
control path (upon ndo_stop()) and not in NAPI context.
> Also I have noticed, in prueth_prepare_rx_chan() pages are allocated per
> number of descriptors for a channel, but they are not being used when a
> packet is being recieved (in emac_rx_packet()) and rather new page is
> allocated for the next upcoming packet. Is this a valid design, what are
> your thoughts on this ?
The new page is possibly a page that was recycled into the pool when a
previous packet was freed / dropped.
[...]
> Yes I will add PP_FLAG_DMA_SYNC_DEV as well.
> I believe page_pool_dma_sync_for_cpu() needs to be called sync Rx page for
> CPU, am I right ? If so can you tell me, in what all cases should I call
> this function.
Before accessing the packet data.
> https://lkml.iu.edu/hypermail/linux/kernel/2312.1/06353.html
> In the above link it is quoted - "Note that this version performs DMA sync
> unconditionally, even if the associated PP doesn't perform sync-for-device"
> for the page_pool_dma_sync_for_cpu() function. So does that mean if I am
> using this function I don't need explicily sync for device call?
It's explained in the page pool documentation:
"Driver is always responsible for syncing the pages for the CPU. Drivers
may choose to take care of syncing for the device as well or set the
PP_FLAG_DMA_SYNC_DEV flag to request that pages allocated from the page
pool are already synced for the device."
https://docs.kernel.org/networking/page_pool.html#dma-sync
next prev parent reply other threads:[~2025-02-05 17:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 12:49 [PATCH net 0/3] Add native mode XDP support Meghana Malladi
2025-01-22 12:49 ` [PATCH net 1/3] net: ti: icssg-prueth: Use page_pool API for RX buffer allocation Meghana Malladi
2025-01-23 17:12 ` Ido Schimmel
2025-02-04 17:55 ` [EXTERNAL] " Malladi, Meghana
2025-02-05 17:41 ` Ido Schimmel [this message]
2025-02-06 14:01 ` Malladi, Meghana
2025-01-22 12:49 ` [PATCH net 2/3] net: ti: icssg-prueth: introduce and use prueth_swdata struct for SWDATA Meghana Malladi
2025-01-22 12:49 ` [PATCH net 3/3] net: ti: icssg-prueth: Add AF_XDP support Meghana Malladi
2025-01-23 17:25 ` Ido Schimmel
2025-02-04 17:55 ` [EXTERNAL] " Malladi, Meghana
2025-02-05 17:46 ` Ido Schimmel
2025-02-06 14:01 ` Malladi, Meghana
2025-01-22 13:13 ` [PATCH net 0/3] Add native mode XDP support Simon Horman
2025-01-23 11:50 ` Meghana Malladi
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=Z6OirBmdSLuY5YkI@shredder \
--to=idosch@idosch.org \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=daniel@iogearbox.net \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=diogo.ivo@siemens.com \
--cc=edumazet@google.com \
--cc=glaroque@baylibre.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m-malladi@ti.com \
--cc=matthias.schiffer@ew.tq-group.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
--cc=schnelle@linux.ibm.com \
--cc=srk@ti.com \
--cc=vigneshr@ti.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.