Re: [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm)

[Karim Manaouil]

On Tue, Jun 09, 2026 at 01:01:21PM +0530, Garg, Shivank wrote:
> 
> 
> On 6/9/2026 5:30 AM, Karim Manaouil wrote:
> > [You don't often get email from kmanaouil.dev@xxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > In my opinion the driver should be at drivers/dma/dcbm, other DMA drivers
> > in the same directory like idxd and sdxi can just export a struct
> > dma_migrator. It makes it easy to have everything in the driver's own
> > directory. For example, idxd has some internals headers as well as an
> > already existing dmaengine implementation in drivers/dma/idxd.
> > 
> > PS. I am writing an implementation of this based on idxd. I'll try to
> > post it soon with numbers.
> > 
> > You can add
> > Reviewed-by: Karim Manaouil <kmanaouil.dev@xxxxxxxxx>
> > 
> 
> Hi Karim,
> 
> Thanks for the review.
> 
> I'm excited to see your idxd based implementation.
> 
> For plain memory to memory copy, which is all migration needs right now,
> the public dmaengine API is good enough, and idxd/sdxi/ptdma ... can
> all work through it. I'm curious which features you're planning to use
> from idxd internal headers that dmaengine can't provide?

Hi Shivank,

I'm still testing, but the initial implementation I wrote with
DMAEngine had too much overhead because of the sgtable allocations
and the conversion between kernel scatterlists to device descriptors.
So I entirely bypassed the DMAEngine API by directly passing the folios
lists to the driver.

I know it depends on the use case. If you just want to offload with no
latency requirements, then DMAEngine is fine, but if the goal is to
achieve high bandwidth with minimal latency, then it's a problem.

Another example, if you have to do several independent copies of 256 or
512 4KiB pages in a short period of time, there will to much stress on
sgtable allocations.

Another problem for low latency is DMA mapping.

Anyway, I need to collect more numbers. I will try to share my insights
with idxd asap.

> Also, my understanding is that driver/dma houses DMA providers,
> whereas DCBM would be consumer of DMAengine APIs. So is that right
> place for it?

I think you're right. It makes more sense when viewed from that
perspective. In fact, maybe at some point we will have some more generic
memory offload infrastructure to support sharing, load balancing across
several acceelrator instances, numa-awareness, handling batching for drivers
and asynchronous offload (to workqueues with completions).

-- 
~karim