Re: [PATCH 1/4 v2] dmaengine: add a tx_free method to struct dma_async_tx_descriptor

On Wed, Dec 10, 2008 at 5:30 PM, Guennadi Liakhovetski
[off-list ref] wrote:

Hi Dan,

On Wed, 10 Dec 2008, Dan Williams wrote:

quoted

On Wed, Dec 10, 2008 at 3:36 AM, Guennadi Liakhovetski
[off-list ref] wrote:

quoted

From: Guennadi Liakhovetski <redacted>

Some users reuse DMA transaction descriptors multiple times and need an
explicit call to release them. An example of such a user is Video4Linux, which
has to be able to release descriptors on ioctl(VIDIOC_DQBUF).

Signed-off-by: Guennadi Liakhovetski <redacted>

Hi Guennadi,

Other dmaengine drivers have tasklets that scan the list of completed
descriptors and free the "acked" ones.  This happens in the cleanup
tasklet...
/me looks
...hmm this driver does not have a cleanup routine?  Ideally support
for ioctl(VIDIOC_DQBUF) could be achieved through this mechanism
without needing to increase the size of dma_async_tx_descriptor (which
has cache utilization impacts on other drivers).

You mean there are drivers, that have struct dma_async_tx_descriptor on
stack?

huh?

And you mean, that increasing the size
of the struct by one pointer and letting users explicitly free those
descriptors when they want is worse than introducing a tasklet that will
have to periodically scan the list of descriptors while other hot paths
will move elements to and from this list, look for acked elements, lock
the list and free those elements? Periodically, because although we have
an event when to free them - on ioctl - there is no API to trigger that
tasklet.

There are a few events that trigger this: completion interrupt,
someone polls is_tx_complete, we run out of descriptors.

Or am I missing something? I can do this, it just sounds strange
to me.

You are missing that existing drivers need to do this anyway to to
handle operation completion actions.  So, while they are at it they
also free the descriptor which relieves client code from needing to
track what it has in-flight versus completed, especially since clients
may not get a handle to each descriptor a driver creates on its
behalf.

What I am suggesting is that other dmaengine drivers would handle this
implicitly after one of the above events...  can this happen in the
ipu_idmac case as well?

Thanks,
Dan