From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750803Ab2LEJks (ORCPT ); Wed, 5 Dec 2012 04:40:48 -0500 Received: from mx0.aculab.com ([213.249.233.131]:56109 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751148Ab2LEJko convert rfc822-to-8bit (ORCPT ); Wed, 5 Dec 2012 04:40:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT Subject: RE: [PATCH v2] net/macb: Use non-coherent memory for rx buffers Date: Wed, 5 Dec 2012 09:35:39 -0000 Message-ID: In-Reply-To: <50BE2FEC.2070500@atmel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v2] net/macb: Use non-coherent memory for rx buffers Thread-Index: Ac3SQvIWJKWSFt+CQJuBZikvA3IQGwAh7Jqw References: <1354536876-6274-1-git-send-email-nicolas.ferre@atmel.com> <50BCA746.1020705@atmel.com> <50BE2FEC.2070500@atmel.com> From: "David Laight" To: "Nicolas Ferre" Cc: "David S. Miller" , , , , "Joachim Eastwood" , "Jean-Christophe PLAGNIOL-VILLARD" , "Havard Skinnemoen" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. > 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. David