lkml.org 
[lkml]   [2008]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [RFC v3 4/7] dmaengine: Add slave DMA interface
Date
>From: Haavard Skinnemoen [mailto:hskinnemoen@atmel.com] 
>Sent: Monday, February 18, 2008 5:30 AM
>To: Nelson, Shannon
>Cc: Haavard Skinnemoen; Williams, Dan J;
>linux-kernel@vger.kernel.org; David Brownell;
>kernel@avr32linux.org; Francis Moreau; Paul Mundt; Vladimir A.
>Barinov; Pierre Ossman
>Subject: Re: [RFC v3 4/7] dmaengine: Add slave DMA interface
>
>On Fri, 15 Feb 2008 09:12:35 -0800
>"Nelson, Shannon" <shannon.nelson@intel.com> wrote:
>
>> I'll jump in here briefly - I'm okay with the direction this
>is going,
>> but I want to be protective of ioatdma performance. As used
>in struct
>> ioat_desc_sw, the cookie and ack elements end up very close
>to the end
>> of a cache line and I'd like them to not get pushed out across the
>> boundry. I don't think this proposal changes the layout, I'm just
>> bringing up my concern.
>
>Sure, performance is very important, and it's good to see that you're
>critical about the changes I'm proposing. That said, the memory layout
>doesn't change at all with this patch -- the fields that didn't go into
>the generic dma descriptor were at the end of the struct to begin with.
>
>I can add a comment saying that cookie and ack must always come first.
>Any other fields that we need to be careful about?
>
>Haavard
>

Those are the only two that I'm worried about at the moment. I'm just
hoping that a quirk in some compiler's struct packing doesn't push them
over that edge.

Thanks,
sln


\
 
 \ /
  Last update: 2008-02-19 19:56    [W:0.111 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site