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.

A few questions about qmss and cppi

Hi,

6678 and ccs 5.3

I have a few questions about using qmss and cppi to communicate:

1. If I want to send packets from one core to another, opening txchannel and rxchannel are a must ,right?

2. If I want to send packets from one core to another, there are  two ways as below using qmss and  cppi?

1>If I only open txchannel and rxchannel,  by calling Qmss_queuePushDesc or Qmss_queuePushDescSize,and then call  Qmss_queueDivert to divert decriptors from txque to rxque. To receive by calling Qmss_queuePop from rxque.

2>open rxflow as well.

3.I saw that all the demo that uses rxflow uses accumulator as well. What’s the relationship between rxflow and accumulator? Is it true that you have to run a accumulator on pdsp if you want to use rxflow?

4. Is it true that interrupt must be configured if accumulator is used?

5. Is it true that queues 704-735 should be used if accumulator and rxflow are used since these queues map to accumulator channels which map to cores ?

6.  what about queues 800-831, these queues are tx queues, they automatically send pakcets to rxqueue if any decriptors pushed to them. But I assume this only happens if rxflow is configured otherwise how these tx queues know which queue to transfer to.right?

Assume that I only want to send one packet from core0 to core1 and I don’t want to use flow.

7.should core0 opens a txque and core1 opens a rxque or should both cores open both queues?

8. Should only core0 opens txchannel and rxchannel?

Thanks

yrj

  • Hi,

    Thanks for your post.

    Please find my answers appropriate to your posted questions:

    #1: Yes, you are right. For instance, inorder to use channel 0, open queue 800, open TX channel 0, RX channel 0, an RX Flow, and whatever RX Q, RX FDQ, and TX FDQ queues that needs to be used. Kindly note that the TX descriptor defines the TX FDQ (and RX Flow) to be used, and the RX Flow defines the RX Q and RX FDQ.

    #2: Once everything is properly initialized, pop a descriptor from the TX FDQ, fill it with data and push it to queue 800. It will flow through the TX DMA, the Streaming I/F, the RX DMA and will be pushed to the RX Q. For example, to make transfer data from core A’s L2 to core B’s L2, the TX FDQ’s descriptors should be in a QMSS memory region located in core A’s L2, and likewise, the RX FDQ’s descriptors needs to be in a QMSS memory region located in core B’s L2.

    #3: It is must that an RX flow should be programmed for every RX transaction. If the application is directly/indirectly driving the PKTDMA’s RX Streaming I/F and if a valid RX flow ID is not specified, the RX DMA will substitute the channel number and use it for the RX flow ID whereas, the accumulator firmware's job is to poll a select number of queues looking for descriptors that have been pushed into them. Later, descriptors are popped from the queue and been placed in a buffer provided by the host. When the list becomes full or a programmed time period expires, the accumulator triggers an interrupt to notify the host to read the buffer for descriptor information.

    #4: Yes for sure, the mapping between accumulator channel and host interrupt is fixed, however, each accumulator channel can be configured to any queue, or can be disabled, so there is a siginificant amount of flexibility in how queues can be mapped to host interrupts. Please check Figure 4-36 (page no. 97) shows the handshaking between the accumulator firmware, the INTD and the host software from the below doc:

    http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf (please refer sections 4.3.4.2, 4.3.4.3)

    #5: Queues 704 to 735 normally used by high priority accumulation. The high priority accumulator uses up to 32 queues, one per channel. Each channel triggers a core-specific interrupt. These queues can also be used as general purpose queues. It has no relevance that both accumulator and rxflows should be used to gether.

    #6: Queues 800 to 831 are mapped to QMSS TX queues which is normally used for infrastructure (core to core) DMA copies and notification.(Kindly refer section 5.1 queue maps and Table 5-1 from sprugr9h doc). Yes, you are right, this cannot happen until rxflow is configured which is a must for every Rx. transaction

    #7: Yes, core0 opens a txque and core1 opens a rxque to send one packet from core0 to core1 but this cannot happen with out rx. flow which is mandatory to be programmed.

    Note: For loopback PKTDMA modes, 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 nonloopback cases, the RX flow is specified in the packet info structure of the Streaming I/F. In the event where no RX flow is specified, the RX DMA willsubstitute the channel number and use it for the RX flow ID.

    #8: No. Core 0 doesn't open both Tx. channel and Rx. channel since only the destination host which is the core1 as per your assumption would open the rx. channel. For more info. on packet transmission and reception overview, kindly refer sections 2.6 and 2.7 from sprugr9h doc.

    Inaddition to above, there are several error situations that can cause the PKTDMA to suddenly stop processing packets, please refer section 6.4 for programming errors and section 6.5 for FAQ's on QMSS/packetDMA from sprugr9h doc.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Thanks for all the details Sivaraj,

    1. I read the demo qmInfraMCExampleProject, I saw

            /* Set tag information */
            tag.destTagLo = 0;
            tag.destTagHi = 0;
            tag.srcTagLo = core;
            tag.srcTagHi = 0;

            Cppi_setTag (Cppi_DescType_MONOLITHIC, monoDescPtr, &tag);

    before qmss_queuepush, so this indicates that this decriptor should be procesed by the flow whose id equals core, right? Does it mean different decriptors can be processed by different flow even if they are pushed into a same queue?

    And the demo also has

        /* Configure flow 0 */
        rxFlowCfg.flowIdNum = channel % NUMBER_OF_CORES;
        /* Get queue manager and queue number from handle */
        queInfo = Qmss_getQueueNumber (rxQueHnd);
        rxFlowCfg.rx_dest_qnum = queInfo.qNum;
        rxFlowCfg.rx_dest_qmgr = queInfo.qMgr;
        rxFlowCfg.rx_sop_offset = MONOLITHIC_DESC_DATA_OFFSET;
        rxFlowCfg.rx_desc_type = Cppi_DescType_MONOLITHIC;
        
        /* Get queue manager and queue number from handle */
        queInfo = Qmss_getQueueNumber (rxFreeQueHnd);
        rxFlowCfg.rx_fdq0_sz0_qnum = queInfo.qNum;
        rxFlowCfg.rx_fdq0_sz0_qmgr = queInfo.qMgr;

        /* Configure Rx flow */
        rxFlowHnd = (Cppi_FlowHnd) Cppi_configureRxFlow (cppiHnd, &rxFlowCfg, &isAllocated);

    This indicates how the flow will process the decriptor, that is , a decriptor that processed by the flow will carry to the queue  rx_dest_qnum defines. right?

    2. But in the demo cppiExampleProject, I don't see srcTagLo being set nor calling configureRxFlow, it only uses Qmss_queueDivert to move the decriptor. However it opens tx and rx channel. So I wonder what's the RX transaction exactly mean? As you mentioned that flow is needed in every RX transaction.

    Thanks,

    yrj

  • Hi,

    Thanks for your update.

    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.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • Thank you Sivaraj,

    I read this in the navigator pdf. I just want to confirm the theory with the demo.

    Can you help me with the question about the cppiExampleProject demo. I still have my doubt.

    Thanks,

    yrj