C6472/TCI6486 - SMMQT example, filler at the end of the msg structure

Mariana

Hi all,

About the smmqt example that can be downloaded at:

http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/MQT/index.html

Customer is asking about the filler at the end of the message structure:

I'm trying to understand the MSGQ object and how to send messages
between multiple cores.
My question is specific on how to generate a structure to hold our
specific data and the filler bytes that are appended at the end.

Looking at the examples provided by TI, it seems that you are using
a filler to align the structures to the cash line boundary !
mqtciv_1_21\packages\ti\bios\drivers\examples\smmqt\evmTCI6486\smmqtest.pjt
mqtciv_1_21\packages\ti\bios\drivers\examples\smmqt\evmTCI6486\smmqtest.c

typedef struct MyMsg {

         MSGQ_MsgHeader header;
         Int            numMsgs;
         Int            seqNum;
    char           filler[_CACHELINE_SIZE - sizeof(MSGQ_MsgHeader) - 2 *
    sizeof(Int)];
    } MyMsg;

The Application Program Interface.pdf page 2-276 does not specify
the need for a filler!

             "Messages in a message queue can be of variable length. The
        *ONLY *requirement is that the first field in the definition of
        a message must be a MSGQ_MsgHeader element."

* My question:*
Do we have to have the filler or not?
and if we DO need that filler, how should we determine its size if
we have large arrays?

I know that it is probably to improve cache performance, bus is it strictly necessary?

over 15 years ago

0 ToddMullanix over 15 years ago

TI__Guru* 96960 points

MSGQ itself has no requirements other than the one you mentioned. The different MSGQ transports might have restrictions. The SMMQT has the restriction that messages passed must be 1) aligned on a cache line boundary and 2) the size of the message must be a multiple of a cache line.

SMMQT is a zero-copy transport. This means when a message is sent, it is NOT copied into shared memory. The pointer to the message (that is in shared memory) is simply placed onto a linked list. If the transport was copy-based (e.g. copy the message into and out of shared memory), the two restrictions would not exist. However, internally, the buffers (in shared memory) managed by the transport would have the restrictions.

So, if there is cache enabled when using the SMMQT, there must be a filler in the messages in the SMPOOL to meet the above two restrictions. Note: SMMQT manages all the cache coherency of the messages when they move between processors (e.g. doing a writeback within the context of the MSGQ_put, doing an invalidate when the message is received on the other core).

If the messages are not on a cache line boundary, or if the message size is not a multiple of the cacheline length, the invalidates and/or writebacks done within SMMQT might corrupt memory since it will be acting on memory that is in an unknown state. Note: this is not a restricton that is unique to SMMQT. It is a general issue with cache and shared memory.

For example, if your message was 40 bytes, and the cacheline size was 128 bytes. When a MSGQ_put is done, the entire cacheline where the 40 byte message resides would be written into physical memory. So the "extra" 88 bytes would be written also. If those 88 bytes were updated by a different core, all the changes the other core made to those 88 bytes would be wiped out by the cache write-back. Similiarly on the receiving side with the invalidates.

Having said all that, there is one nit: the file should have supported the option that no cache was enabled (e.g. _CACHELINE_SIZE=0). In this case, there is no need for a filler, since there are no cache coherency concerns

Todd.

0 Mariana over 15 years ago in reply to ToddMullanix

TI__Mastermind 24340 points

Hi Todd,

Thanks for the explanation.

Is this anywere in the documentation? I gave some clarifications to the customer today and he asked about where is this documented.. I could not find it...

0 ToddMullanix over 15 years ago in reply to Mariana

TI__Guru* 96960 points

The SPRA that comes with the SMMQT (sprab09.pdf or spraai2a.pdf, depending on if it is the catalog transport package or the CIV transport package) describes it in "Cache Concerns" section. The AppNote is in the docs directory. There is also a link to it in the release notes.

0 Mariana over 15 years ago in reply to ToddMullanix

TI__Mastermind 24340 points

Thanks Todd!

One more question from the customer:

In addition, do you have examples on how to use MSGQ to get/putdata from/into the HPI interface?

I do not think we have it, can you confirm that for me?

0 Mariana over 15 years ago in reply to ToddMullanix

TI__Mastermind 24340 points

Ok, thanks for the help!

0 ToddMullanix over 15 years ago

TI__Guru* 96960 points

I don’t know of any MSGQ transport written for the HPI interface.

From: Mariana [mailto:noreply@e2e.ti.com]
Sent: Friday, February 05, 2010 9:13 AM
To: int_multicore_dsp_forum@e2e.ti.com
Subject: Re: [INT - Multi-core DSPs Forum] C6472/TCI6486 - SMMQT example, filler at the end of the msg structure

Thanks Todd!

One more question from the customer:

In addition, do you have examples on how to use MSGQ to get/putdata from/into the HPI interface?

I do not think we have it, can you confirm that for me?

--
View this message online at https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/int-multi-core_dsps/f/114/p/34150/118994.aspx#118994 or reply to this message
Capture this message to a wiki

Processors

Processors forum

C6472/TCI6486 - SMMQT example, filler at the end of the msg structure