On Thu, Oct 13, 2016 at 4:00 AM, Nikita Yushchenko
wrote:
It would make more sense to update the DMA API for
__dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
the direction is DMA_FROM_DEVICE.
>>>
>>> No, in generic case it's unsafe.
>>>
>>> If CPU issued a writ
>>> It would make more sense to update the DMA API for
>>> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
>>> the direction is DMA_FROM_DEVICE.
>>
>> No, in generic case it's unsafe.
>>
>> If CPU issued a write to a location, and sometime later that location is
>> used as DM
From: Alexander Duyck
> Sent: 12 October 2016 19:30
> On Wed, Oct 12, 2016 at 11:12 AM, Nikita Yushchenko
> wrote:
> >> It would make more sense to update the DMA API for
> >> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
> >> the direction is DMA_FROM_DEVICE.
> >
> > No,
On Wed, Oct 12, 2016 at 11:12 AM, Nikita Yushchenko
wrote:
>> It would make more sense to update the DMA API for
>> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
>> the direction is DMA_FROM_DEVICE.
>
> No, in generic case it's unsafe.
>
> If CPU issued a write to a locati
> It would make more sense to update the DMA API for
> __dma_page_cpu_to_dev on ARM so that you don't invalidate the cache if
> the direction is DMA_FROM_DEVICE.
No, in generic case it's unsafe.
If CPU issued a write to a location, and sometime later that location is
used as DMA buffer, there is
On Wed, Oct 12, 2016 at 9:11 AM, Nikita Yushchenko
wrote:
To get some throughput improvement, I propose removal of that
sync_for_device() before reusing buffer. Will you accept such a patch ;)
>>>
>>> Not one that gets rid of sync_for_device() in the driver. From what I
>>> can tell the
>>> To get some throughput improvement, I propose removal of that
>>> sync_for_device() before reusing buffer. Will you accept such a patch ;)
>>
>> Not one that gets rid of sync_for_device() in the driver. From what I
>> can tell there are some DMA APIs that use that to perform the
>> invalidatio
From: Alexander Duyck
> Sent: 12 October 2016 16:33
...
> > To get some throughput improvement, I propose removal of that
> > sync_for_device() before reusing buffer. Will you accept such a patch ;)
>
> Not one that gets rid of sync_for_device() in the driver. From what I
> can tell there are som
On Tue, Oct 11, 2016 at 11:55 PM, Nikita Yushchenko
wrote:
The main reason why this isn't a concern for the igb driver is because
we currently pass the page up as read-only. We don't allow the stack
to write into the page by keeping the page count greater than 1 which
means th
>>> The main reason why this isn't a concern for the igb driver is because
>>> we currently pass the page up as read-only. We don't allow the stack
>>> to write into the page by keeping the page count greater than 1 which
>>> means that the page is shared. It isn't until we unmap the page that
>>
On Mon, Oct 10, 2016 at 10:00 AM, Nikita Yushchenko
wrote:
> Hi Alexander
>
> Thanks for your explanation.
>
>> The main reason why this isn't a concern for the igb driver is because
>> we currently pass the page up as read-only. We don't allow the stack
>> to write into the page by keeping the p
Hi Alexander
Thanks for your explanation.
> The main reason why this isn't a concern for the igb driver is because
> we currently pass the page up as read-only. We don't allow the stack
> to write into the page by keeping the page count greater than 1 which
> means that the page is shared. It i
On Mon, Oct 10, 2016 at 5:27 AM, Nikita Yushchenko
wrote:
>>> Hmm... I'm not about device writing to memory.
>>
>> This absolutely is about whether the device wrote into the
>> area or not.
>
> Not only.
>
>>> Sequence in igb driver is:
>>>
>>> dma_map(full_page)
>>>
>>> sync_to_cpu(half_page)
>> All the data has been synced
>
> Non-synced data is write done by CPU executing upper layers of network stack,
Upper layers shall never get area that is still dma_map()ed and will be
dma_unmap()ed in future. But with igb, this is exactly what happens.
>> Hmm... I'm not about device writing to memory.
>
> This absolutely is about whether the device wrote into the
> area or not.
Not only.
>> Sequence in igb driver is:
>>
>> dma_map(full_page)
>>
>> sync_to_cpu(half_page);
>> skb_add_rx_frag(skb, half_page);
>> napi_gro_receive(skb);
>> .
From: Nikita Yushchenko
Date: Mon, 10 Oct 2016 12:51:28 +0300
> Hmm... I'm not about device writing to memory.
This absolutely is about whether the device wrote into the
area or not.
> Sequence in igb driver is:
>
> dma_map(full_page)
>
> sync_to_cpu(half_page);
> skb_add_rx_frag(skb, half
>> With this scheme, page used for Rx is completely dma_map()ed at
>> allocation time, split into two buffers, and individual buffer is
>> sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
>> while driver driver still uses other buffer. Later, when driver decides
>> to no longer u
From: Nikita Yushchenko
Date: Mon, 10 Oct 2016 11:52:06 +0300
> With this scheme, page used for Rx is completely dma_map()ed at
> allocation time, split into two buffers, and individual buffer is
> sync_to_cpu()ed AND PASSED TO NETWORK STACK via skb_add_rx_frag() -
> while driver driver still use
18 matches
Mail list logo