RE: [RFC v3 4/7] dmaengine: Add slave DMA interface

["Nelson, Shannon" <shannon.nelson@intel.com>]

>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