From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] net/macb: Use non-coherent memory for rx buffers
Date: Wed, 5 Dec 2012 16:12:39 +0100 [thread overview]
Message-ID: <50BF6467.5060701@atmel.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70D9@saturn3.aculab.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "David S. Miller" <davem@davemloft.net>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
Joachim Eastwood <manabian@gmail.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Havard Skinnemoen <havard@skinnemoen.net>
Subject: Re: [PATCH v2] net/macb: Use non-coherent memory for rx buffers
Date: Wed, 5 Dec 2012 16:12:39 +0100 [thread overview]
Message-ID: <50BF6467.5060701@atmel.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B70D9@saturn3.aculab.com>
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
next prev parent reply other threads:[~2012-12-05 15:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-23 13:50 [PATCH] net/macb: Use non-coherent memory for rx buffers Nicolas Ferre
2012-11-23 13:50 ` Nicolas Ferre
2012-11-23 16:12 ` Joachim Eastwood
2012-11-23 16:12 ` Joachim Eastwood
2012-11-26 10:44 ` Nicolas Ferre
2012-11-26 10:44 ` Nicolas Ferre
2012-12-03 12:14 ` [PATCH v2] " Nicolas Ferre
2012-12-03 12:14 ` Nicolas Ferre
2012-12-03 12:43 ` David Laight
2012-12-03 12:43 ` David Laight
2012-12-03 13:21 ` Nicolas Ferre
2012-12-03 13:21 ` Nicolas Ferre
2012-12-03 14:25 ` David Laight
2012-12-03 14:25 ` David Laight
2012-12-04 17:16 ` Nicolas Ferre
2012-12-04 17:16 ` Nicolas Ferre
2012-12-05 9:35 ` David Laight
2012-12-05 9:35 ` David Laight
2012-12-05 15:12 ` Nicolas Ferre [this message]
2012-12-05 15:12 ` Nicolas Ferre
2012-12-05 15:22 ` David Laight
2012-12-05 15:22 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50BF6467.5060701@atmel.com \
--to=nicolas.ferre@atmel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.