Need some explanation about QMSS internal PKTDMA

Hi Andrey,

The C6678 team is notified. They should respond directly here.

Best Regards,
Yordan

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com). Please read all the links below my signature.

Did you go through the online training's from below link,

Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

Thank you ran35366 ,

>> This is the way I look at the PKTDMA channels
>> On the TX side it converts descriptors data into bit stream out
>> On the RX side it converts bit stream to descriptors' data
Such view is close to me too.

I understand that RX data path and TX data path in PKTDMA are completely independent. I understand that main goal of PKTDMA is converting bit streams to\from descriptors.

For example: We transmit data to SRIO. Hardware SRIO block has 16 TX channels (table 5-19) (that are input to SRIO). We configure SRIO PRTDMA, put descriptors into one of SRIO queue, enable at least one of TX channel. After that queue pend signal triggers PKTDMA, PKTDMA gets descriptor from queue, reads data from buffer and sends data to SRIO through one (is it one?) of TX channel. It's SRIO block problem to monitor TX channels and do other work for data transfer to the world. It's clear, but I have one question: how PKTDMA chooses TX channel to communicate with SRIO? Takes first enabled and no busy? Or there are some fixed mapping within TX channels and SRIO TX queues?

But there are some white spaces in my understanding how physically PKTDMA receiving mechanism works.

For example: SRIO has received packet type 9 from external device. SRIO transfers it through one (is it one?) of PKTDMA RX active channel. Or it triggers signal to PKTDMA that something is in input buffer? Also here is the same question: how hardware chooses RX channel? Another problem is that SRIO needs somehow tell to PKTDMA witch RX flow to use. I know that there are RIO_RXU_MAPxx_QID registers. But how this information is transferred to PKTDMA? Are there some info links between SRIO and its PKTDMA beside RX channels? Or info about RX Flow ID and Dest Queue ID is transferred through RX channel? And how Dest_QID from RIO_RXU_MAPxx_QID correlates to RX_DEST_QNUM from RX Flow Configuration Register A? The rest steps of receiving data (taking descriptors from queue and so on) are clear to me.

>> So
>> 1) Does rx and tx channels of QMSS internal PKTDMA are connected to each other? >>>> The output of the TX channel is connected to the input of the RX channels.

Ok, it's clear to me.

>> 2) What is the mapping of this channels? -> If i understand correctly your question, the TX mapping is done by using the QMSS queue (each queue is maped to a channel, look at table 5-1 of the User Guide from above.). The RX channels mapping is in the following question
>> 3) Can I open tx channel #0 and rx channel #1 to make core-to-core transfers or I must use the same channel numbers? -> I think so, need to verify it, but what is the advantage to allow the hardware to connect TX channel N to RX channel M (N=!M)? Why do you need it?

If you say that the outputs of the TX channels are connected to the inputs of the RX channels, then what the scheme of this connections? There are 32 RX and 32 TX channels in QMSS PKTDMA. In case of SRIO I represent to myself that RX and TX channels between SRIO and its PKTDMA are physical links. And if we enable RX (or TX) channel on PKTDMA then SRIO can use it automatically. But in case of QMSS PKTDMA I suggest that we must enable RX and TX channel that are physically connected together. Otherwise nothing will happen. Another question how QMSS PKTDMA determines which RX flow to use when some data is transferred on RX channels? In case of SRIO PKTDMA this information somehow comes from RIO_RXU_MAPxx_QID registers.
I can't say you why I need it, because I don't understand how it works.

>> 4) Does the rx and tx channels are some kind of hardware (physical link between data source\dest (SRIO) and DMA engine), while flow is an abstraction over this hardware? - The RX Flow (this is what you mean?) are actual registers. Follow table 5-14 in the User's Guide

I understand that RX Flow physically is a group of registers. I mean that RX Flow is like a wrapper over channels.


And one more global question: what TI means by the word "channel"? DMA engine inside PKTDMA or bit-stream interface between hardware block (like SRIO, PA) and PKTDMA?

Thanks

Andrey

Thank you ran35366 ,

There are many white spaces in my understanding how it works.

1) Global question: what TI means by word "channel"? Is is DMA engine inside PKTDMA or is it data streaming interface between PKTDMA and hardware block like SRIO or PA?

2) How QMSS PKTDMA determines witch RX flow to use when some data comes in? In case of SRIO PKTDMA there are RIO_RXU_MAPxx_QID registers and FlowID is transferred to PKTDMA somehow.

3) How Dest_QID from RIO_RXU_MAPxx_QID correlates with RX_DEST_QNUM from RX Flow Configuration Register A?

Andrey

1) Global question: what TI means by word "channel"? Is is DMA engine inside PKTDMA or is it data streaming interface between PKTDMA and hardware block like SRIO or PA?
>>>>>>>2.5.1 in the user guide www.ti.com/.../sprugr9h.pdf has ad definition of channel. It is both, hardware different line that connects a queue to the interface and a virtual connection that help priorities multiple users. Let me explain what I mean. Think about SRIO with multiple TX sources. The channel number (that is connected to the queue number) will determine the priorities inside the SRIO hardware.

2) How QMSS PKTDMA determines witch RX flow to use when some data comes in? In case of SRIO PKTDMA there are RIO_RXU_MAPxx_QID registers and FlowID is transferred to PKTDMA somehow.
>>>>>there is something about the Protocol that tells the system what Flow to use. For each interface you need to find the definition of the flow registers and see what information is there. You can think about it like with SRIO type 9, "if the income stream is for stream 5 (or whatever) put the descriptor in queue 200. If this is stream 10 put the descriptor in queue 300"

3) How Dest_QID from RIO_RXU_MAPxx_QID correlates with RX_DEST_QNUM from RX Flow Configuration Register A?
>>>>> refer me to the document and the section where these two are define and I can try and answer


Ran

ran,

ran35366 said:

1) Global question: what TI means by word "channel"? Is is DMA engine inside PKTDMA or is it data streaming interface between PKTDMA and hardware block like SRIO or PA?
>>>>>>>2.5.1 in the user guide www.ti.com/.../sprugr9h.pdf has ad definition of channel. It is both, hardware different line that connects a queue to the interface and a virtual connection that help priorities multiple users. Let me explain what I mean. Think about SRIO with multiple TX sources. The channel number (that is connected to the queue number) will determine the priorities inside the SRIO hardware.

Ok. So TX channel is physical link to interface plus DMA engine to transfer data from buffer memory to interface through this link. And each TX channel has dedicated queue that triggers DMA engine.

Does the physical link of internal QMSS PKTDMA TX and RX channel are connected to each other?

ran35366 said:

2) How QMSS PKTDMA determines witch RX flow to use when some data comes in? In case of SRIO PKTDMA there are RIO_RXU_MAPxx_QID registers and FlowID is transferred to PKTDMA somehow.
>>>>>there is something about the Protocol that tells the system what Flow to use. For each interface you need to find the definition of the flow registers and see what information is there. You can think about it like with SRIO type 9, "if the income stream is for stream 5 (or whatever) put the descriptor in queue 200. If this is stream 10 put the descriptor in queue 300"

There is no problem for SRIO, it has RIO_RXU_MAPxx_QID registers that tell to SRIO PKTDMA what RX Flow to use. But what about internal QMSS PKTDMA? What registers on TX side of this PKTDMA I need to setup to reach certain RX Flow on RX side of PKTDMA?

ran35366 said:

3) How Dest_QID from RIO_RXU_MAPxx_QID correlates with RX_DEST_QNUM from RX Flow Configuration Register A?
>>>>> refer me to the document and the section where these two are define and I can try and answer

From SPRUGW1B (SRIO):

3.9.3.1 RIO_RXU_MAPxx_QID: Dest_QID - Destination Queue ID. This is the final destination for which the payload is targeted

From SPRUGR9H (Multicore Navigator):

4.2.4.1 RX Flow N Configuration Register A: RX_DEST_QNUM - RX Destination Queue. This field indicates the default receive queue that packets on this flow should be placed onto.

What queue number will be used for incoming SRIO packets?

Andrey

At last I found myself answer to the second question about "where RX Flow id comes from?"

FROM Multicore Navigator UG,  2.5.2 RX Flows:

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 nonloopback 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.

But again here is some mystic. Where and when situation may arise when we are working in nonloopback mode and no RX flow is specified? QMSS PKTDMA works only in loopback mode. SRIO PKTDMA will pass RX Flow id from RIO_RXU_MAPxx_QID.

The third question is still opened to me. How Dest_QID from RIO_RXU_MAPxx_QID (SPRUGW1B section 3.9.3.1) correlates with RX_DEST_QNUM from RX Flow Configuration Register A (SPRUGR9H section 4.2.4.1)?

Ran, can you help?

Andrey