• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1444 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320C6678: Descriptors not released from Tx queue

Tzvi E
Intellectual 450 points
Part Number: TMS320C6678


Hello,

We use the SRIO type 9 messages in our system.

At initialization, the Tx free queue is filled with 16 descriptors and in each transaction a descriptor is popped from the Tx free queue, pushed to the Tx queue and after the transmission completion the descriptor is returned automatically to the Tx free queue. This behavior is the normal behavior of the system. 

BUT, there are cases that the SRIO port has an error (e.g. link partner disabled the input port) and this cause the descriptors to be aggregated in the Tx queue (since the packets can't be transmitted to the link partner) until there is no free descriptor in the Tx free queue. Now,  even if the SRIO problem is solved (the link partner established a link and all SRIO alignment and error recovery procedures have been done) the descriptors are still stuck in the Tx queue and not been transmitted (There are several cases that the descriptors are released but in most of the time the descriptors stuck is in the Tx queue). 

my suspicious is that the Tx queue signals the SRIO to pop a descriptor from the Tx queue only after software pushed a descriptor to the Tx queue or after previous transaction has completed, but in case that no descriptor has been pushed to the Tx queue or transaction has completed (like in case that there are descriptors in the Tx queue and error occurred in the system) - no signal is done to release a descriptor from the Tx queue which lead to the phenomena I described earlier.

1. Is there any operation that can force the PKTDMA/SRIO module to start Tx queue transactions after a stuck scenario is detected? Shouldn't it be done automatically?

2. Can you approve/reject my assumption?

Waiting for your advice.

  • 0
    TI__Guru 65405 points
    I've forwarded this to the SW team. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0 in reply to Tzvi E
    TI__Mastermind 43296 points

    Hi Tsvetolin,

    I discussed the descriptor release issue in the case of SRIO link down with the SRIO driver lead developer. It appears there is no packet descriptor cleanup logic to handle descriptors dead in the TX queue has been implemented in the SRIO driver as you suspected. Once the SRIO driver pushes the descriptor into the TX queue it expects CPDMA to take over and move the packet into the SRIO hardware for transmission. You will need to implement some custom cleanup logic to detect a link failure.  In theory, the cleanup logic could A)manually, push all descriptors back onto the TX queue, in correct order, when the link comes back up Or B)pop all descriptors off the tx queue, cleanup the memory attached to each descriptor, then manually push the descriptors onto the free queue.

    Regards, Garrett

  • 0 in reply to Garrett Ding
    Intellectual 450 points

    Hi,

    Thanks for your reply.

    I want to be sure i understand your answer.

    If the SRIO link is down and the CPDMA does not pop a descriptor from the Tx queue for transmission (because the link is down), after some time the link became up again - does the CPDMA pops the descriptors from the Tx queue automatically? In other words - Does the CPDMA has a mechanism to identify the queue depth automatically or does the CPDMA pop a descriptor from the queue only when new descriptor is pushed to the Tx queue?

    Thanks,

  • 0 in reply to Tzvi E
    TI__Mastermind 43296 points
    Tsvetolin,

    The queues have qpend signals that are level triggered. The signal is active anytime there are 1 or more descriptors in the queue, and inactive when there are 0 items in the queue.

    Regards,
    Garrett