6.1.1 System Planning

Multicore Navigator is a complex peripheral to program due to its many setup options and its connections to other system peripherals. This requires thorough, coordinated planning on how to allocate Multicore Navigator resources for whatever uses the system will require of it. For best efficiency, Multicore Navigator is designed to be initialized at system start with an allocation of resources large enough to support it and not to be reconfigured at run-time, though there is support for this (such as the teardown of PKTDMA channels). Resources requiring up-front consideration are:

1. Descriptor memories. First, the decision for using host or monolithic packets must be made (generally, monolithic are simpler to use, but host provide more flexibility). Next, the sizes of the descriptor memories must be considered. The QM can be configured with 20 different descriptor regions, and each region supports only one descriptor size. (Note, for monolithic use this means a maximum of 20 different descriptor sizes can be specified; for host mode, the linked buffers can still be any size). Finally, the required number of descriptors must be known. Because descriptors can be recycled both in TX and RX transactions, extra descriptors are needed to make sure the free descriptor pools do not run dry (a condition called starvation).
2. Queue allocation. With more than 7,300 general purpose queues, it should not be difficult to organize a functional layout of queues. Because the QM does not access any part of the descriptor or data buffers, there is no penalty for using one queue over another (though the placement of descriptor memory in L2 or DDR will have performance effects). Also, remember that each TX queue will require a TX completion queue and RX queues require free descriptor queues. It is possible though to have several TX queues completing to a common TX completion queue, and the same for RX queues. Another consideration is the powerful use of chaining – the output queue of one peripheral being the input queue of another, and so on. This requires careful planning of queue use and recycling.
3. System memory. With the allocation of descriptors comes the obvious need to allocate and partition chunks of memory for descriptor and buffer use, and also the decision of which memories (L2, DDR, etc.) to use. Another less obvious consideration is the programming of the descriptor region itself: The descriptor size must be a multiple of 16 bytes, and the number of descriptors in the region is specified as a power or 2, beginning with 2⁵. These restrict the region’s possible size, especially when large numbers of descriptors are required.
4. TIP1: You can program a descriptor region that is larger than you allocate memory for, but the region’s start indexes and the link RAM sizes must be consistent with the programmed values. This will mean allocating a larger link RAM than will be used, but this is more than offset by not allocating the full size descriptor region. In other words, programming a larger than actual descriptor region helps to get around the coarse power of 2 sizing of the region. Caveats to this:
   1. You must make absolutely sure that no other memory region resides within the programmed memory space of another region.
   2. You can use these phantom descriptors in the QM only, because the QM does not touch memory. But you must not try to pass them through the PKTDMA.
5. TIP2: You must program a descriptor region with a fixed size, but you do not have to use every descriptor. As long as each descriptor is a multiple of the programmed size (which, itself, is a multiple of 16 bytes), you can use contiguous descriptors to create a single larger descriptor. The host must manage how it tracks the different sized descriptors.
6. RX flows. RX flows can have a powerful effect on memory usage. Through careful programming, the RX DMA can be configured to select a particular FDQ based on packet size, or by Host buffer number within the packet.
7. Recycling and garbage collection. Descriptor fields provide for specifying which queues the descriptors should be recycled to once the TX DMA has finished with them. It is recommended to use this feature in TX transfers. For RX, the host is responsible for requiring descriptors to the RX FDQ.