SRIO RX Buffer allocate problem

Tommy

You may want to change the  SRIO_MAX_MTU for a larger payload. Take a look at this e2e to answer your question.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/199765/711981.aspx#711981

Elush

Cache synchronization ?

Hi Ted cooper,

Sorry for a delayed response; I did not see a verified answer for this, so I will put in some tidbits I noticed about the SRIO DIO example. The root of the problem is memory management and how the OSAL allocates memory for SRIO.

• Like you indicated, you will have to increase the systemHeap in the .cfg file for space to allocate bigger buffers. And as such, for payloads of 1MB, putting it in MSMC is a valid choice.
• In the function, Osal_dataBufferInitMemory, there is a call Osal_local2Global. This should NOT be done for addresses not in L2. For example, if you are allocating a buffer in MSMC, this would return an invalid address. I added an if statement, if ((int)ptrMemory > 0x00800000 && (int)ptrMemory < 0x00880000), to this call.
• Next is how the memory is initialized. In it's default state, a SRIO_MAX_MTU size buffer is needed for every RX/TX buffer for the SRIO Driver (that's indicated by numRxBuffers and numTxBuffers, respectively) as well as every source and destination buffer the application uses (srcDataBuffer and dstDataBuffer, respectively). The max number of SRIO_MAX_MTU sized buffers is held by the variable MAX_MEM_MGR_ENTRIES. At the beginning of the application, the program will try to allocate a chunk of space equal to SRIO_MAX_MTU x MAX_MEM_MGR_ENTRIES. Already we can see that if you increase SRIO_MAX_MTU size carelessly, you will run into out-of-memory problems. If you decrease the number of MAX_MEM_MGR_ENTRIES, the program may not have enough buffer entries to run.
• The misleading thing is that numRxBuffers and numTxBuffers do not really come into play for DIO operations. The SRIO_MAX_MTU x MAX_MEM_MGR_ENTRIES chunk of space is handled by gDataBufferMemMgr. Subsequent OSAL call to Osal_srioDataBufferMalloc and Osal_srioDataBufferFree will simply operate on gDataBufferMemMgr, without any actual need for Memory_alloc or Memory_free.
• srcDataBuffer and dstDataBuffer will try to use an entry from gDataBufferMemMgr if they use Osal_srioDataBufferMalloc. Instead, try changing the SIZE_DIO_PACKET to the size of the packet you want to send, and then using Memory_alloc. Eg. srcDataBuffer[i] = (uint8_t*)Memory_alloc(NULL, SIZE_DIO_PACKET, 16, &errorBlock); -- this would also apply for using Memory_free instead of Osal_srioDataBufferFree
• Remember, srcDataBuffer and dstDataBuffer are also declared based on the number of SRIO sockets opened times the number of transfer. You can play around with this, but for a huge transfer, you may want to try SRIO_DIO_LSU_ISR_NUM_SOCKETS = 1, and SRIO_DIO_LSU_ISR_NUM_TRANSFERS = 1 first.
• Now comes some of the cache issues. You will have to do a cache writeback whenever you update the src/dstDataBuffers and a cache invalidate after the SRIO send operation. I recommend grabbing the SYS/BIOS api from ti/sysbios/hal/Cache.h since we are already using BIOS. EDIT: Just want to point out that cache management should be handled via the application and not the driver. "SRIO send" is a bit ambiguous, since the Srio_sockSend_DIO function can be configured for NREAD or NWRITE ttypes. Cache invalidate would only be needed for the receiving end of the SRIO operation.