On Thu, Apr 21, 2016 at 4:39 PM, Christoph Hellwig wrote:
> On Thu, Apr 21, 2016 at 04:37:42PM +0300, Or Gerlitz wrote:
>> On Wed, Apr 20, 2016 at 9:40 PM, Eran Ben Elisha
>> wrote:
>> >> It is been 1.5 years since I reported the problem. We came
On Thu, Apr 21, 2016 at 4:39 PM, Christoph Hellwig wrote:
> On Thu, Apr 21, 2016 at 04:37:42PM +0300, Or Gerlitz wrote:
>> On Wed, Apr 20, 2016 at 9:40 PM, Eran Ben Elisha
>> wrote:
>> >> It is been 1.5 years since I reported the problem. We came
On Thu, Apr 21, 2016 at 04:37:42PM +0300, Or Gerlitz wrote:
> On Wed, Apr 20, 2016 at 9:40 PM, Eran Ben Elisha
> wrote:
> >> It is been 1.5 years since I reported the problem. We came up with three
> >> different solutions this week. I'd like to see a version of the
On Wed, Apr 20, 2016 at 9:40 PM, Eran Ben Elisha
wrote:
>> It is been 1.5 years since I reported the problem. We came up with three
>> different solutions this week. I'd like to see a version of the solution
>> to get merged until Mellanox comes up with a better
On 4/20/2016 2:40 PM, Eran Ben Elisha wrote:
>>
>> It is been 1.5 years since I reported the problem. We came up with three
>> different solutions this week. I'd like to see a version of the solution
>> to get merged until Mellanox comes up with a better solution with another
>> patch. My proposal
>
> It is been 1.5 years since I reported the problem. We came up with three
> different solutions this week. I'd like to see a version of the solution
> to get merged until Mellanox comes up with a better solution with another
> patch. My proposal is to use this one.
>
We will post our
Sinan Kaya wrote:
I'd like to see a version of the solution
to get merged until Mellanox comes up with a better solution with another
patch.
Yes, I agree 100%.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation
Apologies,
Replied to an older post by mistake. I was trying to reply to Eran.
>Hi Sinan,
>
>We are working in Mellanox for a solution which
>removes the vmap call and allocate contiguous memory (using
>dma_alloc_coherent).
>
>Thanks,
>Eran
>
>
>On 4/20/2016 9:35 AM, Sinan Kaya wrote:
> On
On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
> What I think we need is something like the patch below. In the long
> ru nwe should also kill the mlx4_buf structure which now is pretty
> pointless.
>
It is been 1.5 years since I reported the problem. We came up with three
different solutions
Hi Sinan,
We are working in Mellanox for a solution which
removes the vmap call and allocate contiguous memory (using dma_alloc_coherent).
Thanks,
Eran
On Tue, Apr 19, 2016 at 9:37 PM, Sinan Kaya wrote:
> On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
>> What I think we
On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
> What I think we need is something like the patch below. In the long
> ru nwe should also kill the mlx4_buf structure which now is pretty
> pointless.
Maybe; this could be the correct approach if we can guarantee that the
architecture can allocate
What I think we need is something like the patch below. In the long
ru nwe should also kill the mlx4_buf structure which now is pretty
pointless.
---
>From a493881d2a6c90152d3daabb7b6b3afd1d254d78 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 19 Apr 2016 14:12:14
On 4/18/2016 11:40 AM, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote:
>> I was looking at the code. I don't see how removing virt_to_page + vmap
>> would solve the issue.
>>
>> The code is trying to access the buffer space with direct.buf member
>> from the
On 4/18/2016 11:40 AM, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote:
>> I was looking at the code. I don't see how removing virt_to_page + vmap
>> would solve the issue.
>>
>> The code is trying to access the buffer space with direct.buf member
>> from the
On 4/18/2016 11:59 AM, David Miller wrote:
> From: ok...@codeaurora.org
> Date: Mon, 18 Apr 2016 01:06:27 -0400
>
>> On 2016-04-18 00:00, David Miller wrote:
>>> From: Sinan Kaya
>>> Date: Sat, 16 Apr 2016 18:23:32 -0400
>>>
Current code is assuming that the address
From: ok...@codeaurora.org
Date: Mon, 18 Apr 2016 01:06:27 -0400
> On 2016-04-18 00:00, David Miller wrote:
>> From: Sinan Kaya
>> Date: Sat, 16 Apr 2016 18:23:32 -0400
>>
>>> Current code is assuming that the address returned by
>>> dma_alloc_coherent
>>> is a logical
On Mon, Apr 18, 2016 at 11:21:12AM -0400, Sinan Kaya wrote:
> I was looking at the code. I don't see how removing virt_to_page + vmap
> would solve the issue.
>
> The code is trying to access the buffer space with direct.buf member
> from the CPU side. This member would become NULL, when this
On 4/18/2016 11:15 AM, Timur Tabi wrote:
> Sinan Kaya wrote:
>>
>> VMAP allows you to make several pages look contiguous to the CPU.
>> It can only be used against logical addresses returned from kmalloc
>> or alloc_page.
>>
>> You cannot take several virtually mapped addresses returned by
>>
On 4/18/2016 11:17 AM, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 02:39:36PM +, Eli Cohen wrote:
>> Right, I did not suggest this as a patch but just wanted to pinpoint the
>> problematic issue which is that virt_to_page does not give you the correct
>> pointer to the page.
>
>
On Mon, Apr 18, 2016 at 02:39:36PM +, Eli Cohen wrote:
> Right, I did not suggest this as a patch but just wanted to pinpoint the
> problematic issue which is that virt_to_page does not give you the correct
> pointer to the page.
Removing both the virt_to_page + vmap calls would solve the
Sinan Kaya wrote:
VMAP allows you to make several pages look contiguous to the CPU.
It can only be used against logical addresses returned from kmalloc
or alloc_page.
You cannot take several virtually mapped addresses returned by
dma_alloc_coherent
and try to make them virtually contiguous
Cohen <e...@mellanox.com>
Cc: Sinan Kaya <ok...@codeaurora.org>; linux-r...@vger.kernel.org;
ti...@codeaurora.org; c...@codeaurora.org; Yishai Hadas <yish...@mellanox.com>;
netdev@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH V2] net: ethernet: mellanox: corre
On Mon, Apr 18, 2016 at 09:54:47AM +0300, Eli Cohen wrote:
> Sinan,
>
> if we get rid of the part this code:
>
> if (BITS_PER_LONG == 64) {
> struct page **pages;
> pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
>
Sure, this is not the complete patch. As far as I know the problem
you're facing with arm is that virt_to_page() does not provide the
correct page descriptor so my suggestion will eliminate the need for
it.
On Mon, Apr 18, 2016 at 09:53:30AM -0400, Sinan Kaya wrote:
> On 4/18/2016 2:54 AM, Eli
On Mon, Apr 18, 2016 at 09:49:10AM -0400, Sinan Kaya wrote:
> Here is a good description of logical address vs. virtual address.
>
> https://www.quora.com/What-is-the-Kernel-logical-and-virtual-addresses-What-is-the-difference-between-them-What-is-the-type-of-addresses-listed-in-the-System-map
On 4/18/2016 9:10 AM, Christoph Hellwig wrote:
> On Mon, Apr 18, 2016 at 09:06:18AM -0400, ok...@codeaurora.org wrote:
>> On 2016-04-18 08:12, Christoph Hellwig wrote:
>>> On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote:
Current code is assuming that the address returned by
On 4/18/2016 2:54 AM, Eli Cohen wrote:
> Sinan,
>
> if we get rid of the part this code:
>
> if (BITS_PER_LONG == 64) {
> struct page **pages;
> pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
> if (!pages)
On Mon, Apr 18, 2016 at 09:06:18AM -0400, ok...@codeaurora.org wrote:
> On 2016-04-18 08:12, Christoph Hellwig wrote:
> >On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote:
> >>Current code is assuming that the address returned by dma_alloc_coherent
> >>is a logical address. This is not
On 2016-04-18 08:12, Christoph Hellwig wrote:
On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote:
Current code is assuming that the address returned by
dma_alloc_coherent
is a logical address. This is not true on ARM/ARM64 systems.
Can you explain what you mean with a 'logical
On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote:
> Current code is assuming that the address returned by dma_alloc_coherent
> is a logical address. This is not true on ARM/ARM64 systems.
Can you explain what you mean with a 'logical address' and what actual
issue you're trying to
Sinan,
if we get rid of the part this code:
if (BITS_PER_LONG == 64) {
struct page **pages;
pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
if (!pages)
goto err_free;
On 2016-04-18 00:00, David Miller wrote:
From: Sinan Kaya
Date: Sat, 16 Apr 2016 18:23:32 -0400
Current code is assuming that the address returned by
dma_alloc_coherent
is a logical address. This is not true on ARM/ARM64 systems. This
patch
replaces dma_alloc_coherent
From: Sinan Kaya
Date: Sat, 16 Apr 2016 18:23:32 -0400
> Current code is assuming that the address returned by dma_alloc_coherent
> is a logical address. This is not true on ARM/ARM64 systems. This patch
> replaces dma_alloc_coherent with dma_map_page API. The address
Current code is assuming that the address returned by dma_alloc_coherent
is a logical address. This is not true on ARM/ARM64 systems. This patch
replaces dma_alloc_coherent with dma_map_page API. The address returned
can later by virtually mapped from the CPU side with vmap API.
Signed-off-by:
34 matches
Mail list logo