On 04/17/2018 02:52 PM, Dave Jiang wrote:
On 04/17/2018 02:31 PM, Sinan Kaya wrote:
On 4/17/2018 5:21 PM, Dave Jiang wrote:
Given we have few users of DMA Engine, I believe we should try to keep as
much functionality as possible in the kernel to allow new features to be
developed rather than limiting people's choices.
Would love to see more in kernel consumers for dmaengine. Maybe things
that help accelerate core kernel bits? :)
Side conversation...
I'm on the same boat. I have been thinking about this for some time.
I also know that Intel maintains a repo in sourceforge for experimental
work that was never upstreamed.
What kind of things could be useful for DMA engine optimization?
1. async_tx removal because it's kind of broken.
2. channel hotplug in case future hardware has virtual channels instead
of physical fixed?
3. device hotplug? idk
4. maybe instead of having a giant group of dmaengine ops, we move it
towards a single API call and pass in command context? Perhaps a
resemblance to blk-mq type of structures? That way, every time we have a
new op, we don't need to add yet another function pointer. We also have
a source SG and a destination SG. That way it should cover virtual or
DMA memory right? I wonder how it would work for RAID operations though....
Just random ideas I'm throwing out there.
Continue on same topic, one of biggest concerns we have with choosing
dmaengine is number of methods we have to call to queue a descriptor to
hardware:
1. prep
2. submit
3. issue pending
Understand the flexibility this provide, but it's too much of overhead
for most transfers. We use scatterlist when can to package a burst
transfer. But it's not ideal solution either because we still have to
create a list, then dmaengine will again walk thru the same list. So if
we can provide immediate ops that queue hardware immediately would be great.
I was told that most of the kernel data structures are resident and cannot
be paged but then I hear about kernel virtual memory allocated by vmalloc
that it makes me nervous.
What worked until now and what failed?
That was the series. After doing some testing, we didn't see the
performance we wanted with IOATDMA so we decided to put that on hold for
now.
https://lists.01.org/pipermail/linux-nvdimm/2017-August/011962.html
I understand that pinning pages is the biggest challenge. What else?
Given that some of the qcom DMA engines can do virtual memory, that
means you won't have to worry about pinning pages? Do the DMA engines do
page faulting for you with the virtual address? That would make pinning
pages a non-issue no?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
