linux-kernel - Re: dmaengine/Query: What about scatter/gather for mem to mem transfers.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1324372895.1641.10087.camel@vkoul-udesk3>
Date:	Tue, 20 Dec 2011 14:51:35 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Pratyush Anand <pratyush.anand@...com>
Cc:	"Williams, Dan J" <dan.j.williams@...el.com>,
	Viresh KUMAR <viresh.kumar@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	Armando VISCONTI <armando.visconti@...com>,
	Deepak SIKRI <deepak.sikri@...com>,
	Vipin KUMAR <vipin.kumar@...com>,
	Vipul Kumar SAMAR <vipulkumar.samar@...com>,
	Vincenzo FRASCINO <Vincenzo.FRASCINO@...com>,
	Mirko GARDI <mirko.gardi@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Amit VIRDI <Amit.VIRDI@...com>,
	Bhupesh SHARMA <bhupesh.sharma@...com>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>
Subject: Re: dmaengine/Query: What about scatter/gather for mem to mem
 transfers.

On Thu, 2011-12-15 at 12:26 +0530, Pratyush Anand wrote:
> >> That way existing mechanism would work well for you.
> >> You need to split the chunks properly, which is what dma would do
> anyway
> >>
> >
> > Yes, they can be split like this, but then splitting onus will go on
> dma
> > user driver, and so there would be replication of similar logic at
> > several places. Therefore, I was thinking to make device_prep_dma_sg
> as
> > generic by adding these flags.
Well I am not sure how adding flags handles this?
There are few things you should consider
1) do you have h/w support for these, if yes then we can talk about
dmaengine APIs doing such a thing
2) if objective is to support such transfers from dma driver POV, then I
wouldn't agree, as these can be split easily to standard dma sg list.
>>From the code POV, it wouldn't hurt to create a wrapper which take in
these non standard sg list list and converts then to uniform list

Most important question:
in which practical scenario would src and dstn lengths be different?

> 
> I see one more issue in using device_prep_interleaved_dma.
> 
> Src and Dst address has been allocated in user space.
> Now a kernel module extracts physical addresses from these pages and
> prepares a sg list, which it submits to DMA.
> These addresses would be virtually contiguous and incrementing. But,
> I 
> am not sure if they are always physically incrementing too. If they
> are 
> not guaranteed to be incrementing, then I see issue.
> 
> Otherwise also, a situation can arise when scattered memory is not 
> always incrementing or decrementing in the same sg list.
What _exactly_ are you trying to do?

DMA would need buffers which are physically contagious. Also the user
pages can be swapped out, you would need to pin these pages.

-- 
~Vinod

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