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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BAE9DCEF64577A439B3A37F36F9B691C040CB607@orsmsx418.amr.corp.intel.com>
Date:	Tue, 19 Feb 2008 10:46:54 -0800
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	"Williams, Dan J" <dan.j.williams@...el.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [RFC v3 4/7] dmaengine: Add slave DMA interface

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