NvSciIpc Channel Memory
NvSciIpc shared memory region is divided into two identical FIFOs: one FIFO on which the caller sends data, and one FIFO on which the caller receives data. The elements within FIFO are called Frame. Both FIFOs have an equal number (frame count) of frames, and all frames are a uniform fixed length (frame size).
Producer (or sender) constructs a message and sends it to FIFO. The FIFO queue keeps this message until the consumer is available. When a consumer is ready to process the message, it consumes the message from FIFO. The user can communicate remotely, as unidirectional point to point style, or bindirectional RPC (Remote Procedure Call) style (the producer sends a message and expects a response from the consumer).
The shared memory operation of NvSciIpc is similar with message queue logically.
NvSciIpc is a simple lightweight communication layer that can be used to send and receive raw data. NvSciIpc doesn't provide error checking (such as CRC) or control field, which has frame length or frame type since they are overhead. The client is responsible for implementing or maintaining them.
Determining the Frame Size
Frame Size is the maximum data size which the producer (or sender) or consumer (or
receiver) can send/receive with a single
NvSciIpcWriteSafe()/NvSciIpcReadSafe()
API call.
In considering cache coherency, frame size should be aligned with 64 bytes. There is no upper limit in frame size.
NvSciIpc supports fixed-length frames, but if you need a variable-length frame
protocol, set the max data size to the frame size and have the header (control
field) and payload data structure for each frame. The header field might have frame
length or user frame type information. User can peek a specific header field using
the NvSciIpcReadGetNextFrame()
API before reading data using
NvSciIpcReadSafe()
.
Determining the Frame Count (= Queue Capacity)
The frame count depends on statistics (or usecases) of the user communication model. If the frame count is too small, an overflow/underflow issues may occur and messages may not be processed in time. This can cause unwanted flow control signaling and lead to performance degradation. If the frame count is too large, memory is wasted and processing efficiency is degraded. Choosing the right frame count is important for optimizing system performance (use the power of 2 as the frame count test value: 2, 4, 8, 16, 32, 64, 128, 256, 512 ...).
There is no upper limit with the frame count. You might need a higher frame count for buffering frames in case of streaming or burst mode communication.
For throughput-critical usecases, higher frame counts typically increase throughput, but once the frame count exceeds a certain value, throughput no longer increases.
Total Channel Memory Size
Frame Size (in Bytes) x Frame Count x 2 (bidirectional FIFO)