lkml.org 
[lkml]   [2008]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <olof@lixom.net> wrote:
> > Dummy descriptors that do nothing but cause an interrupt is the intent.
>
> Well, it'd be slightly more efficient to do add the interrupt attribute
> to the last issued descriptor when it's known in advance. If the
> underlying driver doesn't support it, adding a separate descriptor would
> be a good fallback.
>

When it is known in advance the interrupt attribute *is* set,
otherwise the descriptor may already be in flight.

> Anyway, this isn't likely to be a performance bottleneck. If it turns
> out to be, I'll refactor it and submit patches.
>

Would not hurt to have another pair of eyes on this part of the code.
A rewrite of the channel switch mechanism is currently pending in
async_tx.git#upstream.

[..]
> > > Can't do that if it's called both from the polling as well as the IRQ
> > > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> > > support it will be needed.
> > >
> >
> > ...do it in a tasklet.
>
> Why? That just adds overhead and latency.
>

The original ioat_dma code used nothing heavier than spin_lock_bh.
Async_tx now assumes that local_bh_disable prevents races with any
channel's cleanup routine. Clients can place the same kind of code in
an async_tx callback as they would in a timer callback. The
assumption is that code using async_tx can afford its extra overhead,
which is true for raid. This is also why you don't see async_memcpy
calls in net_dma.

--
Dan


\
 
 \ /
  Last update: 2008-03-14 01:09    [W:2.308 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site