Hello,
We have an application that follows the example of multicoreExample to send out packets to Ethernet.
Below is the SendPacket() function in cppi_qmss_mgmt.c.
Int32 SendPacket (Void) { Cppi_HostDesc* pCppiDesc; UInt32 dataBufferSize; uint32_t key; ...
...
...
/* Send the packet out the mac. It will loop back to PA if the mac/switch * have been configured properly */ Qmss_queuePushDescSize (gPaTxQHnd[8], pCppiDesc, SIZE_HOST_DESC); /* Increment the application transmit counter */ gTxCounter ++; /* Give some time for the PA to process the packet */ CycleDelay (10000); return 0; }
At the end it has a delay of 10000 cycles, and the comment says "Give some time for the PA to process the packet"
In our application, we have to increase the delay to 80000 cycles to avoid packet loss. This is unacceptable, as a lot of processing power is wasted in this long wait.
Why do we need to have this wait? As I understand, gPaTxQHnd[8] is opened as CPSW queue. Ideally the queue should serve as a buffer and the CPU should not have to wait for the CPSW to put the packets out the MAC.
In our code, we implemented a mechanism to have a free queue of size 1, and once a packet is pushed into CPSW queue, we wait for the buffer to show up in the free queue before another push. Even with this change, the packet loss still happens if we remove the delay.
The CPSW statistics do not indicate any dropped TX packets.
Is it possible that the CPSW queue may get into some overflow condition when packets are pushed too quickly into the queue? Is there anything we can try to further locate the problem?
Urgently need your help.
Thanks,
Daniel