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

[Nelson, Shannon]

>From: Haavard Skinnemoen [mailto:hskinnemoen@xxxxxxxxx] 
>Sent: Monday, February 18, 2008 5:30 AM
>To: Nelson, Shannon
>Cc: Haavard Skinnemoen; Williams, Dan J; 
>linux-kernel@xxxxxxxxxxxxxxx; David Brownell; 
>kernel@xxxxxxxxxxxxxx; 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@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/