linux-kernel - Re: [PATCH 02/18] dmaengine, async_tx: add a "no channel switch" allocator

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]

Date:	Tue, 15 Sep 2009 10:28:46 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	"Sosnowski, Maciej" <maciej.sosnowski@...el.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>
Subject: Re: [PATCH 02/18] dmaengine, async_tx: add a "no channel switch"
 allocator

Sosnowski, Maciej wrote:
> Williams, Dan J wrote:
>> Channel switching is problematic for some dmaengine drivers as the
>> architecture precludes separating the ->prep from ->submit.  In these
>> cases the driver can select ASYNC_TX_DISABLE_CHANNEL_SWITCH to modify
>> the async_tx allocator to only return channels that support all of the
>> required asynchronous operations.
>>
>> For example MD_RAID456=y selects support for asynchronous xor, xor
>> validate, pq, pq validate, and memcpy.  When
>> ASYNC_TX_DISABLE_CHANNEL_SWITCH=y any channel with all these
>> capabilities is marked DMA_ASYNC_TX allowing async_tx_find_channel() to
>> quickly locate compatible channels with the guarantee that dependency
>> chains will remain on one channel.  When
>> ASYNC_TX_DISABLE_CHANNEL_SWITCH=n async_tx_find_channel() may select
>> channels that lead to operation chains that need to cross channel
>> boundaries using the async_tx channel switch capability.
>>
>> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
>> ---
> 
> Signed-off-by: Maciej Sosnowski <maciej.sosnowski@...el.com>
> 
> with one question:
> 
>> +	/* note: this only matters in the
>> +	 * CONFIG_ASYNC_TX_DISABLE_CHANNEL_SWITCH=y case
>> +	 */
>> +	if (device_has_all_tx_types(device))
>> +		dma_cap_set(DMA_ASYNC_TX, device->cap_mask);
> 
> Why not to put this part plus device_has_all_tx_types()
> into #ifdef CONFIG_ASYNC_TX_DISABLE_CHANNEL_SWITCH then?
> 

Because device_has_all_tx_types() already has the necessary ifdefs per 
operation type, and it does not rule out the possibility that code 
outside of async_tx can make use of DMA_ASYNC_TX capability.  We don't 
gain anything by eliminating this call... although we would save an 
entry in the dmaengine channel table by turning off DMA_ASYNC_TX in enum 
dma_transaction_type.  But we have already cleaned up 
dma_transaction_type in this patchset so the net change from 2.6.31 to 
2.6.32 is still positive in this area.

--
Dan
--
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/