On 12/05/2012 10:35 AM, David Laight : >> If I understand well, you mean that the call to: >> >> dma_sync_single_range_for_device(&bp->pdev->dev, phys, >> pg_offset, frag_len, DMA_FROM_DEVICE); >> >> in the rx path after having copied the data to skb is not needed? >> That is also the conclusion that I found after having thinking about >> this again... I will check this. > > You need to make sure that the memory isn't in the data cache > when you give the rx buffer back to the MAC. > (and ensure the cpu doesn't read it until the rx is complete.) > I've NFI what that dma_sync call does - you need to invalidate > the cache lines.
The invalidate of cache lines is done by dma_sync_single_range_for_device(, DMA_FROM_DEVICE) so I need to keep it. >> For the CRC, my driver is not using the CRC offloading feature for the >> moment. So no CRC is written by the device. > > I was thinking it would matter if the MAC wrote the CRC into the > buffer (even though it was excluded from the length). > It doesn't - you only need to worry about data you've read. > >>> I was wondering if the code needs to do per page allocations? >>> Perhaps that is necessary to avoid needing a large block of >>> contiguous physical memory (and virtual addresses)? >> >> The page management seems interesting for future management of RX >> buffers as skb fragments: that will allow to avoid copying received data. > > Dunno - the complexities of such buffer loaning schemes often > exceed the gain of avoiding the data copy. > Using buffers allocated to the skb is a bit different - since > you completely forget about the memory once you pass the skb > upstream. > > Some quick sums indicate you might want to allocate 8k memory > blocks and split into 5 buffers. Well, for the 10/100 MACB interface, I am stuck with 128 Bytes buffers! So this use of pages seems sensible. On the other hand, it is true that I may have to reconsider the GEM memory management (it one is able to cover 128-10KB rx DMA buffers)... Best regards, -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
