On 29.10.2015 [18:49:55 -0700], David Miller wrote:
> From: Nishanth Aravamudan
> Date: Thu, 29 Oct 2015 08:57:01 -0700
>
> > So, would that imply changing just the NVMe driver code rather than
> > adding the dma_page_shift API at all? What about
> > architectures that can support the larger page
From: Nishanth Aravamudan
Date: Thu, 29 Oct 2015 08:57:01 -0700
> So, would that imply changing just the NVMe driver code rather than
> adding the dma_page_shift API at all? What about
> architectures that can support the larger page sizes? There is an
> implied performance impact, at least, of s
On Thu, Oct 29, 2015 at 08:57:01AM -0700, Nishanth Aravamudan wrote:
> On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote:
> > We had a quick cht about this issue and I think we simply should
> > default to a NVMe controler page size of 4k everywhere as that's the
> > safe default. This is al
On 29.10.2015 [04:55:36 -0700], Christoph Hellwig wrote:
> On Wed, Oct 28, 2015 at 01:59:23PM +, Busch, Keith wrote:
> > The "new" interface for all the other architectures is the same as the
> > old one we've been using for the last 5 years.
> >
> > I welcome x86 maintainer feedback to confir
On Wed, Oct 28, 2015 at 01:59:23PM +, Busch, Keith wrote:
> The "new" interface for all the other architectures is the same as the
> old one we've been using for the last 5 years.
>
> I welcome x86 maintainer feedback to confirm virtual and DMA addresses
> have the same offset at 4k alignment,
On Tue, Oct 27, 2015 at 05:54:43PM -0700, David Miller wrote:
> From: "Busch, Keith"
> Date: Tue, 27 Oct 2015 22:36:43 +
>
> > If you're suggesting to compile-time break architectures that currently
> > work just fine with NVMe, let me stop you right there.
>
> Silently "working" without the
On 27.10.2015 [17:53:22 -0700], David Miller wrote:
> From: Nishanth Aravamudan
> Date: Tue, 27 Oct 2015 15:20:10 -0700
>
> > Well, looks like I should spin up a v4 anyways for the powerpc changes.
> > So, to make sure I understand your point, should I make the generic
> > dma_get_page_shift a co
From: Julian Calaby
Date: Wed, 28 Oct 2015 10:43:35 +1100
> You'll be CCing the maintainers of each architecture on the patches to
> add the functions, so if they do have specific requirements, I'm sure
> they'll let you know or provide patches.
People miss things, maintainers get busy, so while
From: "Busch, Keith"
Date: Tue, 27 Oct 2015 22:36:43 +
> If you're suggesting to compile-time break architectures that currently
> work just fine with NVMe, let me stop you right there.
Silently "working" without the architecture maintainer having to explicity
look at the new interface and m
From: Nishanth Aravamudan
Date: Tue, 27 Oct 2015 15:20:10 -0700
> Well, looks like I should spin up a v4 anyways for the powerpc changes.
> So, to make sure I understand your point, should I make the generic
> dma_get_page_shift a compile-error kind of thing? It will only fail on
> architectures
On Wed, 2015-10-28 at 10:43 +1100, Julian Calaby wrote:
> Hi Nishanth,
> You'll be CCing the maintainers of each architecture on the patches
> to
> add the functions, so if they do have specific requirements, I'm sure
> they'll let you know or provide patches.
That sort of accross-all-arch change
Hi Nishanth,
On Wed, Oct 28, 2015 at 10:40 AM, Nishanth Aravamudan
wrote:
> On 28.10.2015 [09:57:48 +1100], Julian Calaby wrote:
>> Hi Nishanth,
>>
>> On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan
>> wrote:
>> > On 26.10.2015 [18:27:46 -0700], David Miller wrote:
>> >> From: Nishanth Arav
On 28.10.2015 [09:57:48 +1100], Julian Calaby wrote:
> Hi Nishanth,
>
> On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan
> wrote:
> > On 26.10.2015 [18:27:46 -0700], David Miller wrote:
> >> From: Nishanth Aravamudan
> >> Date: Fri, 23 Oct 2015 13:54:20 -0700
> >>
> >> > 1) add a generic dma
Hi Nishanth,
On Wed, Oct 28, 2015 at 9:20 AM, Nishanth Aravamudan
wrote:
> On 26.10.2015 [18:27:46 -0700], David Miller wrote:
>> From: Nishanth Aravamudan
>> Date: Fri, 23 Oct 2015 13:54:20 -0700
>>
>> > 1) add a generic dma_get_page_shift implementation that just returns
>> > PAGE_SHIFT
>>
>>
On Tue, Oct 27, 2015 at 03:20:10PM -0700, Nishanth Aravamudan wrote:
> On 26.10.2015 [18:27:46 -0700], David Miller wrote:
> > From: Nishanth Aravamudan
> > Date: Fri, 23 Oct 2015 13:54:20 -0700
> >
> > > 1) add a generic dma_get_page_shift implementation that just returns
> > > PAGE_SHIFT
> >
>
On 26.10.2015 [18:27:46 -0700], David Miller wrote:
> From: Nishanth Aravamudan
> Date: Fri, 23 Oct 2015 13:54:20 -0700
>
> > 1) add a generic dma_get_page_shift implementation that just returns
> > PAGE_SHIFT
>
> I won't object to this patch series, but if I had implemented this I
> would have
From: Nishanth Aravamudan
Date: Fri, 23 Oct 2015 13:54:20 -0700
> 1) add a generic dma_get_page_shift implementation that just returns
> PAGE_SHIFT
I won't object to this patch series, but if I had implemented this I
would have required the architectures to implement this explicitly,
one-by-one.
[Sorry, subject should have been 0/7!]
On 23.10.2015 [13:54:20 -0700], Nishanth Aravamudan wrote:
> We received a bug report recently when DDW (64-bit direct DMA on Power)
> is not enabled for NVMe devices. In that case, we fall back to 32-bit
> DMA via the IOMMU, which is always done via 4K TCEs
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
19 matches
Mail list logo