From: Ilias Apalodimas Date: Fri, 17 Feb 2023 22:21:30 +0000 (+0200) Subject: page_pool: add a comment explaining the fragment counter usage X-Git-Tag: v6.6.7~3490^2~1 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=4d4266e3fd321fadb628ce02de641b129522c39c;p=platform%2Fkernel%2Flinux-starfive.git 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 Signed-off-by: Ilias Apalodimas Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/r/20230217222130.85205-1-ilias.apalodimas@linaro.org Signed-off-by: Jakub Kicinski --- diff --git a/include/net/page_pool.h b/include/net/page_pool.h index 34bf531..ddfa0b3 100644 --- a/include/net/page_pool.h +++ b/include/net/page_pool.h @@ -277,6 +277,16 @@ void page_pool_put_defragged_page(struct page_pool *pool, struct page *page, unsigned int dma_sync_size, bool allow_direct); +/* pp_frag_count represents the number of writers who can update the page + * either by updating skb->data or via DMA mappings for the device. + * We can't rely on the page refcnt for that as we don't know who might be + * holding page references and we can't reliably destroy or sync DMA mappings + * of the fragments. + * + * When pp_frag_count reaches 0 we can either recycle the page if the page + * refcnt is 1 or return it back to the memory allocator and destroy any + * mappings we have. + */ static inline void page_pool_fragment_page(struct page *page, long nr) { atomic_long_set(&page->pp_frag_count, nr);