Commit 4d4266e3 authored by Ilias Apalodimas's avatar Ilias Apalodimas Committed by Jakub Kicinski
Browse files

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: default avatarAlexander Duyck <alexanderduyck@fb.com>
Signed-off-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
Link: https://lore.kernel.org/r/20230217222130.85205-1-ilias.apalodimas@linaro.org


Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parent a00da30c

include/net/page_pool.h

+10 −0
Original line number Diff line number Diff line
@@ -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);