Skip to content

Commit 4d4266e

Browse files
apaloskuba-moo
authored andcommitted
page_pool: add a comment explaining the fragment counter usage
When reading the page_pool code the first impression is that keeping two separate counters, one being the page refcnt and the other being fragment pp_frag_count, is counter-intuitive. However without that fragment counter we don't know when to reliably destroy or sync the outstanding DMA mappings. So let's add a comment explaining this part. Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
1 parent a00da30 commit 4d4266e

File tree

1 file changed

+10
-0
lines changed

1 file changed

+10
-0
lines changed

include/net/page_pool.h

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -277,6 +277,16 @@ void page_pool_put_defragged_page(struct page_pool *pool, struct page *page,
277277
unsigned int dma_sync_size,
278278
bool allow_direct);
279279

280+
/* pp_frag_count represents the number of writers who can update the page
281+
* either by updating skb->data or via DMA mappings for the device.
282+
* We can't rely on the page refcnt for that as we don't know who might be
283+
* holding page references and we can't reliably destroy or sync DMA mappings
284+
* of the fragments.
285+
*
286+
* When pp_frag_count reaches 0 we can either recycle the page if the page
287+
* refcnt is 1 or return it back to the memory allocator and destroy any
288+
* mappings we have.
289+
*/
280290
static inline void page_pool_fragment_page(struct page *page, long nr)
281291
{
282292
atomic_long_set(&page->pp_frag_count, nr);

0 commit comments

Comments
 (0)