[BBDev - assistance] Operations executions shouldn't be asynchronous?

[BBDev - assistance] Operations executions shouldn't be asynchronous?

[Mattia Milani]

Hi All,

I've originally written this message on dpdk@dev but received now 
answer, I'm
forwarding it hear int he hope somebody could give me his opinion :)

I'm currently experimenting with BBDev, in particular with the decoding 
operations
and there is something that is puzzling me. I'm sorry if in reality this 
is just a
misunderstanding from my side, but I would really appreciate some 
clarifications.

What I expected was the following:

Once I call the function `rte_bbdev_enqueue_dec_ops` with a certain number
of operations and a specific queue_id I expect the function to append 
the operations
to a queue and return, after that I can use `rte_bbdev_dequeue_dec_ops` 
to read
an "output_queue" structure to obtain the operations already processed 
by the
decoder (the number of op. returned could differ from the number of op. 
enqueued).
My assumption is that the decoder works in an asynchronous way in 
respect to the
process that it's enqueuing operations, and dequeuing the once concluded 
(this last
one could even be another separate process from the op. producer).
Such that, if the queues are empty the decoder has nothing to do, but if 
there are
operations in the queue the decoder is going to execute them, while the 
producer(s)
and consumer(s) can do something else.

What I've understood from the source code:

Once the function `rte_bbdev_enqueue_dec_ops` is called then, there is a 
sequence
of functions calls, up to the point where, in `enqueue_dec_all_ops`
(drivers/baseband/turbo_sw/bbdev_turbo_software.c:1724), there is a for 
loop that take
care of each operation one by one. At this point, for each operation, the
`enqueue_dec_one_op` cycles until there is nothing more to decode 
calling `process_dec_cb`.
This last function executes both `bblib_turbo_adapter_ul` and later 
`bblib_turbo_decoder`.

This sequence of calls never gives back the control to the original 
function which called
`rte_bbdev_enqueue_dec_ops`, that has to wait for all the operations to 
be concluded
before continuing.

The same logic applies for both Turbo and LDPC, from what I've see in 
`enqueue_ldpc_dec_all_ops`.

Now my question is, shouldn't the decoder being built with the first 
approach in mind?
By any chance, is the asynchronous part controlled by FlexRAN? I've to 
admit that I didn't
check more deeply.
Am I missing something in the code that invalidate what I've understood?

I'm of the opinion that an approach like the first one would be more 
resilient and ductile,
separating the logic that controls the queue(s) from the one that 
executes the actual processing.
This way we could simulate more stressful situations where the growing 
rate of the
operations is greater that the outgoing rate from the decoder.

Thank you very much for your help.

Best regards,
Mattia Milani