Are multiple releases of a grant with partial data possible?

[hvraven]

I have a project where I use a bbqueue to queue data for UART transmit. Several produces shove data into the queue and a single consumer hands the data over to the DMA engine.

The problem I am facing is that if I have a lot of data in the buffer (and a simple approach) the read grants become large. This creates large requests to the DMA engine which take a long time to finish. In the meantime the complete read grant is blocked, even though we could start reusing data as soon as the DMA engine has transmitted it. The current work around is to limit the size of the read grant, but that comes at the cost of reduced DMA efficiency.

A relatively simple optimisation would be to periodically read the status of the DMA engine and release the amount of bytes already transferred. However release() consumes self. Is it fundamentally possible to perform multiple release operations, or would this break part of the internal logic?

[titaniumtraveler]

A relatively simple optimisation would be to periodically read the status of the DMA engine and release the amount of bytes already transferred. However release() consumes self. Is it fundamentally possible to perform multiple release operations, or would this break part of the internal logic?

Definitely possible. The underlying Coord::release_inner() only takes &bbq_handle.

Though it might be simpler to implement this by .release()ing the transferred bytes and directly reacquiring the read grant.
That would also have the benefit that the consumer also gets the fresh view of the produced data that was committed while the DMA engine was busy.

@jamesmunns Maybe some convenience method like StreamGrantR::release_and_refresh(&mut self, used: usize) might be a good idea for this usecase, but it definitely isn't necessary to achieve this behavior.

(That of cause assumes that repeated calls to Coord::read() and Coord::release_inner() like this isn't expensive, but I am very much sure it is not.)