QMSS Buffer Management

Hi Tugrul,

Are your questions, when a descriptor is output of a coprocessor, if we can safely modify the buffer which is tied to the descriptor?

The answer is yes.  Once a descriptor is on an output queue, it is considered that no coprocessor has ownership of the descriptor.  So we are allowed to update the buffer associated with the descriptor.

On the other hand, once a descriptor is pushed to a queue which is the input of a hardware accelerator, it is considered that the accelerator has ownership.  In other words, the accelerator is allowed to refer it anytime.  In the case, we should NOT touch the descriptor or the corresponding buffer.

The above is my understanding.  Does it answer to your questions?

Regards,
Atsushi

Hi Atsushi;

Thanks for the fast reply..

Actually my question is not about updating the descripter of an output queue. I will update it then give it to another coprocessor input queue. So, one coprocessors output descripter will be another coprocessors input descripter. Is this possible  ? Here a problem occurs about free descripter queue I guess. After getting the descripter, second coprocessor needs to push the free descripter to a free queue. But in my case the descripter belongs to first coprocessor ( Because it is the same descripter which I get from first coprocessor output queue). Therefore if we configure first and second coprocessor with the same free descripter queue then it seems it will work but i am not sure that it is possible or not ?

My second question is related with the first case. Let us assume that in my case, first coprocessor is FFT and second coprocessor is BCP. It is obvious that i dont always use these coprocessor like the previous example. So i should not strickly configure BCP to push its free descripters to FFT free descripter queue. For instance i know we may write on descripter the output queue of the coprocessor. My second question is about that. Considering my first case, is it also possible to configure the free descripter queue like the output queue of a coprocessors?

I know still it is complicated.. I wish it is clear now..

Regards

Tugrul 

Tugrul,

Sorry for my hasty reply.  Before answering again, I think I should check the coprocessors manual carefully.  But in general, I believe we can configure the output queue of a coprocessor as the input queue of another coprocessor if format of the descriptor and the buffer meets requirements of the coprocessors.  This is a key concept of Multicore Navigator, I think.

Regarding the specific coprocessors, a guru may reply but I will check documentation too.

Regards,
Atsushi

Tugrul,

Please let me try to answer your questions even though I'm still not familiar with the specific coprocessors.  I confirmed that both FFTC and BCP have Tx channels and also Rx channels according to the Table 4-23 PKTDMA Channel and Flow Counts in the SPRUGR9F.

In general, when an Rx channel needs to handle a descriptor, it consults with the corresponding "Rx flow".  An Rx flow refers the fields RX_FDQn_QMGR and also RX_FDQn_QNUM in the RX Flow N Configuration Register D and obtain a free descriptor from the FDQ.  On the other hand, after updating the buffer, the Rx channel pushes the descriptor to the queue which RX_DEST_QMGR and RX_DEST_QNUM in the RX Flow N Configuration Register A.  In short, an Rx channel refers only information in an Rx flow.  When a coprocessor pops a free descriptor and pushes to another queue, it consults with only an Rx flow.

On the other hand, when a Tx channel (probably of another coprocessor) needs to receive a descriptor, it always pops from the hardware-wired queue.  For example, BCP Tx channels always monitor queues #868 to #875 in the C6670 case.  (Please refer the table 5-1 of the SPRUGR9F.)  Once a Tx channel received a descriptor, it processes the buffer and return the descriptor to a Tx completion queue.  The Tx channel decides the number of the Tx completion queue by looking at the Packet Return Queue Mgr # and also Packet Return Queue # which are stored in the received descriptor.  In other words, this decision is completely independent from the information in an Rx flow in the Rx channel case.

To summarize, we can configure a coprocessor A and B as following.

• The coprocessor A get a free descriptor from the RX_FDQn_QMGR and RX_FDQn_QNUM shown in the corresponding Rx flow, putting data in the buffer, and pushes the descriptor into RX_DEST_QNUM of the RX_DEST_QMGR, which are also shown in the Rx flow.  The RX_DEST_QMGR and RX_DEST_QNUM should be the following hardware-wired queue which the coprocessor B monitors.

• The coprocessor B gets the descriptor (which carries data) from the hardware-wired queue (for example #868), process the data, and return the descriptor to a Tx completion queue (shown in the Packet Return Queue Mgr# and Queue # of the descriptor).  The Tx completion queue should be RX_FDQn_QNUM of the RX_FDQn_QMGR which the Rx flow of the coprocessor A Rx channel refers.

By this way, a descriptor will trip between the Rx channel of the coprocessor A and also the Tx channel of the coprocessor B.

I still concern that the above explanation does not completely answer to your questions, but I hope it gives some suggestion to you.

Regards,
Atsushi

Atsushi;

I am really appreciate for your detailed answer. It completely answer my question. This is also the answer for my second question.After your answer I look at Multicore Navigator User Guide and I saw the return queue field in packet descripter. Because there is such a field in packet descripter we have the flexibility to change return queue for different packets. And also as you said we may trip the descripter between coprocessor A & B. This is what I want to learn. 

Many thanks.

Regards

Tugrul