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
<<attachment: johnathan.vcf>>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
