Messages in this thread | | | Date | Fri, 26 Apr 2019 17:37:37 +0200 | From | Andrew Lunn <> | Subject | Re: [PATCH 08/12] net: ll_temac: Fix iommu/swiotlb leak |
| |
On Fri, Apr 26, 2019 at 03:43:20PM +0100, Robin Murphy wrote: > On 26/04/2019 15:21, Andrew Lunn wrote: > >On Fri, Apr 26, 2019 at 09:32:27AM +0200, Esben Haabendal wrote: > >>Unmap the actual buffer length, not the amount of data received. > > > >Hi Esben > > > >The patch Subject does not seem to match the content? > > > >Also, there can be performance advantages of just unmapping the > >received length. The unmap operation does a cache invalidate, which > >can be expensive. Consider the effort of unmapping a 64 byte ACK vs 9K > >jumbo frame? > > If the size passed to dma_unmap_*() is not the same as was passed to the > corresponding dma_map_*(), that is fundamentally incorrect use of the API > and may lead to warnings, resource exhaustion, or possibly even corruption > and crashes for some DMA API implementations. > > If there's a case where you just need to look at a small part of the buffer > right now, but can unmap the whole thing properly later. then > dma_sync_single_*() does allow operating on partial buffers. Even better, if > you're able to recycle buffers in your Rx pool you could potentially replace > the unmap/map dance altogether with some careful use of sync_single.
Hi Robin
Thanks for the info.
I went back to the driver i was thinking of, and it is using dma_sync_single_range_for_cpu() for just the received packet length.
Sorry for the mixup.
Andrew
| |