On Wed, Jan 03, 2018 at 09:58:49AM -0500, David Miller wrote: > From: Neil Horman <nhor...@tuxdriver.com> > Date: Wed, 3 Jan 2018 09:44:15 -0500 > > > A few spots in 3c59x missed calls to dma_mapping_error checks, casuing > > WARN_ONS to trigger. Clean those up. While we're at it, refactor the > > refill code a bit so that if skb allocation or dma mapping fails, we > > recycle the existing buffer. This prevents holes in the rx ring, and > > makes for much simpler logic > > > > Note: This is compile only tested. Ted, if you could run this and > > confirm that it continues to work properly, I would appreciate it, as I > > currently don't have access to this hardware > > > > Signed-off-by: Neil Horman <nhor...@redhat.com> > > CC: Steffen Klassert <klass...@mathematik.tu-chemnitz.de> > > CC: "David S. Miller" <da...@davemloft.net> > > Reported-by: tedheads...@gmail.com > > See my other reply. > > Your RX handling must become more sophisticated. > Yes, I understood your previous reply.
> This is exactly what we tell driver authors to do. If you cannot allocate > or DMA map a replacement RX buffer, you _MUST_ recycle the existing buffer > back to the chip rather than pass it up to the stack. > Thats exactly what this patch does, instead of creating a second loop to traverse all the emptied ring buffers, now I: 1) Pre-allocate a new skb when I know I'm going to receive the in-place skb 2) Map the skb into the appropriate dma device domain 3) If (1) and (2) succede, then I swap the newly allocate skb and dma address with the old one and recieve the old into the network stack 4) If (1) or (2) fail, then I goto clear_complete, which leaves the old skb and dma address in place, sets the buffer status back to 0 (indicating completion), and write the new ring status back to the hardware This is what you wanted, a pre-allocate and swap-if-successful, recycle-if-not approach, rather than the leave-a-hole-in-the-ring approach that is there currently, no? Or did I miss something else? Neil
