Dear Developers,
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
