On Tue, Apr 17, 2018 at 02:52:38PM -0700, 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. Yes > 2. channel hotplug in case future hardware has virtual channels instead > of physical fixed? We should model future work on virtual channels.. > 3. device hotplug? idk Doesnt seem to be a requirement for embedded cases, do you see this for server cases.. > 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.... that is very much required, not sure if we will have one api but a couple should be doable.. -- ~Vinod -- 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
