some questions on QMSS

Hi,

Messiah said:

1, In the Multicore Navigator user guide , queue800～queue831 are used as QMSS TxQs. I wanna know that if we can use other queues as QMSS TxQs and could queue800～queue831 can be used for other purposes?

From UG, looks like other queues cannot be used as QMSS TX Qs. I will have to check if QMSS TXQs have dedicated hardware associated with it, if they do (and I suspect they do) you cannot use them as GP Qs.

Messiah said:

2. In table 5-4 of Multicore Navigator user guide ,is the word ‘channel’ within ‘High Priority channel’ and ‘Tx channel’ with the same meaning, namely, is the High Priority Channel a Tx channel or Rx channel ?

The 'channel' refers to the PktDMA channel.

For questions 3-6, let me get help from someone who is familiar with those projects.

Messiah said:

4. In the qmInfraMCExampleProject, when I make cfg.channel = 1, core1 seems to be the only core used to receive packet, how does it know which core the packets should be sent to when my Tx channel and Rx channel is 0?Can I believe that ‘cfg.channel = 1’ means that the accumulator will trigger an interrupt in core1?

5. In the qmInfraMCExampleProject, why do we have to respectively build rxFreequeue, txFreequeue and txCompletionQueue in core1,core2 and core3? It seems that these queues are never been used.

6. Do we have to build the freeTxQ before building TxQ in the same core?(the same question with RxQ and freeRxQ)

#4: Given you mention 4 cores I assume you are using 6670 but this applies equally to the other keystone devices as well (but please find the appropriate section in your device's userguide to get the exact queue number and the modulo).  The 6670 is in http://www.ti.com/lit/ds/symlink/tms320c6670.pdf.  See table 7-38 on page 158 where it shows "QM_INT_HIGH_n" where "n" is the core number.  This shows that there is a hardcoded mapping of your channel number (which is just queue number - 704) to the core number.  Each core sees 8 queues/channels but they are stepped modulo 4.  This explains why channel 1 appears only on core 1.   Channels 0,4,8,12,16,20,24,28 map to core 0, channels 1,5,9,13,17,21,25,29 map to core 1, and so on.

#5: the sysInit() function only runs on core 0.  See the line "if (coreNum == SYSINIT)" near the top of main().

#6: you can build the queues in any order as long as no transactions are started until they are built.

Messiah said:

3. If I want to transmit messages from core0 to core1 , in the examples given in the ‘qmInfraMCExampleProject‘ we can see that RxQ is built in core0 which is used to receive packets, so may I believe that the RxQ can be built in any of the two cores? But how the core1 get the packets?

Core 1 can get the packets regardless of who builds the RX free queue assuming the pointers returned by the queue managers are valid from core 1's point of view.  Since the pkt dma requires global addresses (even if you fed core 0's local RAM into the RX free queue), the other cores can also see the contents of the pointers.  You would have to play some explicit tricks to make this NOT true by programming different mappings into the MPAX units (either in core 0+1 MPAX or the SES MPAX which is in the MSMC) and for most simple cases this isn't done.

1. You noticed that these queues are queue-pend, means that pushing a descriptor into these queue will generate a signal to the PKTDMA (infarastructure) to read the descriptor and move it to the QMSS channels.  If you do not use these queues for QMSS TX, I am not sure how the infrastructure PKTDMA knows that there is a waiting descriptor.

2.  Can you update your question with the table in the latest  Navigator of what device?  Tables are slightly different between different versions. So I know what table your refer to.

3. Recieve queue can be any queue connected to any core.  The following is a copy from the User's gUide of 6678 (2.5.2 in September 2011 revision) that can explain:

For transmit, the Tx DMA engine uses the information found in the descriptor fields
to determine how to process the Tx packet. For receive, the Rx DMA uses a flow. A flow
is a set of instructions that tells the Rx DMA how to process the Rx packet. It is
important to note that there is not a correspondence between Rx channel and Rx flow,
but rather between Rx packet and Rx flow. For example, one peripheral may create a
single Rx flow for all packets across all channels, and another may create several flows
for the packets on each channel.
For loopback PKTDMA modes (i.e. infrastructure cases), the Rx flow is specified in the
Tx descriptor, in the SOURCE_TAG_LO field. The PKTDMA will pass this value to the
streaming I/F as flow index. In non-loopback cases, the Rx flow is specified in the packet
info structure of the Streaming I/F. In the event no Rx flow is specified, the Rx DMA
will use Rx flow N for Rx channel N.

4. I think that the above apply to question number 4 as well

5. You may be right.  I need to check on the example

6. I don't think that the order of opening queues is important.  But they all have to be opened before descriptors are pushed into them...