• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSGQ_alloc design flaw?

Konrad Gdowski
Prodigy 230 points


Hi

MSGQ_alloc(Uint16 poolId, MSGQ_Msg *msg, Uint16 size);

This is MSGQ_alloc declaration in DSPLINK.

It uses Uint16 as size type. This type has maximum value of 65535. With C64x cache line should be 128 bytes aligned.

Let's suppose we want to allocate 65536 bytes and we had set "match exact size" for the POOL to "true".

The only workaround to allocate 65536 bytes is to set "match exact size" to false, and send request for 65535 bytes, but this could be problematic for POOL management.

Am I right, or have I misunderstood something?

Kind regards

Konrad

  • 0
    TI__Guru* 96960 points

    Hi Konrad,

    When MSGQ was designed, we wanted to keep the header relatively small, so one of the things we did was limit the size to a Uint16. The thought was that messages are generally small. Large buffers could be managed with the CHAN module (or SIO in DSP/BIOS). As more people started to use MSGQ, we heard complaints similar to yours. In the next version of MSGQ (MessageQ in SYS/BIOS and SysLink) we upped the size to UInt32.

    One approach that some customers use is to pass the pointer to the larger buffer (and it's size) in a message. Unfortunately, then you have to perform the cache management on that buffer yourself. Also, this approach does not work well if you are on a multi-processor system that does not have shared memory.

    Todd