Re: [PATCH 3/3] wifi: ath12k: rely on page_pool APIs for buffer allocation

[Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

> 
> 
> On 10/8/2026 9:16 PM, Lorenzo Bianconi wrote:
> > Convert the Rx refill buffers to the page_pool API instead of allocating
> > an skb with dev_alloc_skb() and mapping it with dma_map_single(). The pool
> > handles the DMA mapping and buffer recycling.
> > 
> > Add a page_pool to struct dp_rxdma_ring, created in
> > ath12k_dp_rxdma_ring_buf_setup() and destroyed in
> > ath12k_dp_rxdma_ring_buf_cleanup().
> > 
> > Update ath12k_dp_unmap_rx_buf() to sync page_pool buffers for the CPU
> > instead of unmapping them, and guard the teardown paths
> > (ath12k_dp_cc_cleanup(), ath12k_dp_h_msdu_buffer_type()) against
> > page_pool buffers. In the re-inject path, sync an already mapped
> > page_pool buffer for the device instead of mapping it again, and fill the
> > descriptor with the DMA address stored in the rxcb.
> > 
> > The monitor, CE and TX paths are left unchanged.
> > 
> > This is just preliminary support: the goal is to use a single page to map
> > two separated fragments of 2048B.
> 
> why? please always justify your motivation in detail when the change is not trival.

my main goal here would be to avoid running dev_alloc_skb()/dma_{map,unmap}() on every
rx packets but rely on page_pool APIs in order to recycles and keep pages DMA
mapped. I guess this way we will have even a smaller memory footprint.

> 
> Besides, instead of preliminary patches, why not just send the full support in a single
> series?
> 

I would like to implement it incrementally (you can find the code here [0]) but
I am fine to squash patches in the next iteration.

Regards,
Lorenzo

[0] https://github.com/LorenzoBianconi/wireless-next/tree/b4/ath12k-pp-dev

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]