Re: [Discuss-gnuradio] [coproc] Domain concept for blocks and ports

[Johnathan Corgan]

On 11/06/2013 09:44 AM, Ben Hilburn wrote:

> I've been mulling over this, and I like this design a lot. I think it
> provides a lot of flexibility while also preventing any particular
> scenario from becoming a "corner case". I'm still thinking about it and
> trying to find somewhere to poke a hole, but at a high-level I think it
> is really straight-forward.

I agree with this assessment.  Based on some discussion work we had at
the GNU Radio conference, we also came up with a design for asking GNU
Radio to delegate memory allocation for block output buffers to blocks
themselves, to allow them to create their own doubly-mapped userspace
memory regions out of physical pages they control.

In this design, a block indicates to GNU Radio that it needs to allocate
the memory for either its input buffer (actually, the upstream block's
output buffer) or its own output buffer, by adding a flags field to the
io_signature and having one of the possible flags be WE_OWN.

Once all the blocks are created, and the connectivity between is
established, then GNU Radio can parse the topology and buffer flags to
know which blocks get standard GNU Radio allocated host memory buffers,
and which blocks need to be asked for a prepared memory region to use
for either its output buffer or its upstream block output buffer.  This
would be implemented by an additional overridable virtual function that
would get called by the runtime with the itemsize and count, and return
with the allocated host memory region.

The changes to GNU Radio are very minimal in this respect--adding flags
to io_signature, adding a function to gr_block, and adding logic during
buffer allocation to either use GNU Radio's allocator or a block's
allocator.  This is completely general and can be used to allow blocks
communicating with whatever underlying hardware to manage things in
whatever way is needed, creating the physical-to-virtual mappings with
whatever constraints the hardware needs.  The GNU Radio work function
"contract" imposes a few requirements for doubly mapping physical pages
to virtual pages, but we weren't able to come up with any examples that
weren't solvable from with the block.

A few topological problems arise that aren't solved yet by this, such as
having adjacent accelerator blocks that both want to own the shared
memory buffer.  The suggestion here is to use the above mechanism to
create a domain crossing "sink" block and a domain crossing "source"
block as endpoints in a hierarchical block that also instantiates
whatever logic is needed to do the chained accelerators inside.

Thus, again with minimally invasive changes to the GNU Radio internals,
this mechanism supports both single accelerator blocks as well as the
domain crossing sources and sinks.

Finally, this solution is orthogonal to the desired capability of having
in-place processing blocks.  It can be implemented fairly rapidly, even
in a 3.7 API compatible way, and gives the hooks for additional work to
implement block's requesting in-place semantics vs. the existing
streaming semantics.

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

johnathan.vcf
Description: Vcard

signature.asc
Description: OpenPGP digital signature