RE: [PATCH net] net: xilinx: axienet: Increment Rx skb ring head pointer after BD is successfully allocated in dmaengine flow

[Gupta, Suraj]

[Public]

> -----Original Message-----
> From: Jakub Kicinski <kuba@xxxxxxxxxx>
> Sent: Monday, August 11, 2025 10:13 PM
> To: Pandey, Radhey Shyam <radhey.shyam.pandey@xxxxxxx>
> Cc: Gupta, Suraj <Suraj.Gupta2@xxxxxxx>; andrew+netdev@xxxxxxx;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; pabeni@xxxxxxxxxx; Simek,
> Michal <michal.simek@xxxxxxx>; sean.anderson@xxxxxxxxx;
> horms@xxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Katakam, Harini
> <harini.katakam@xxxxxxx>
> Subject: Re: [PATCH net] net: xilinx: axienet: Increment Rx skb ring head
> pointer after BD is successfully allocated in dmaengine flow
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Mon, 11 Aug 2025 15:55:02 +0000 Pandey, Radhey Shyam wrote:
> > > That wasn't my reading, maybe I misinterpreted the code.
> > >
> > > From what I could tell the driver tries to give one new buffer for
> > > each buffer completed. So it never tries to "catch up" on previously
> > > missed allocations. IOW say we have a queue with 16 indexes, after
> > > 16 failures (which may be spread out over
> > > time) the ring will be empty.
> >
> > Yes, IIRC there is 1:1 mapping for RX DMA callback and
> > axienet_rx_submit_desc(). In case there are failure in
> > axienet_rx_submit_desc() it is not able to reattempt in current
> > implementation. Theoretically there could be other error in
> > rx_submit_desc() (like dma_mapping/netdev
> > allocation)
> >
> > One thought is to have some flag/index to tell that it should be
> > reattempted in subsequent axienet_rx_submit_desc() ?
>
> Yes, some kind of counter of buffer that need to be allocated.
> The other problem to solve is when the buffers are completely depleted there
> will be no callback so no opportunity to refill.
> For drivers which refill from NAPI this is usually solved by periodically
> scheduling NAPI.
I think even after this same problem will exist in dmaengine flow because main problem here is axidma descriptor is freed after invoking callback. Callback (axienet_rx_cb()) will try to request new descriptor in rx_submit_desc(), but it won't be free till that time.
One possible solution I can think of is together with NAPI, having some DMAengine interface invoked by AXIDMA (similar to callback, say post_cb()) after freeing descriptor, which requests new descriptor from AXIDMA?