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.

Rx descriptor queue problem EMAC

Hey to all,

I´am currently working on a DM814x! I´ve setup an rx-descriptor queue with 3 descriptors as following:

descriptor 1 --> next descriptor pointer: descriptor 2

descriptor 2 --> next descriptor pointer: descriptor 3

descriptor 3 --> next descriptor pointer: descriptor 1

So I´am expecting an endless loop! At the RX-ISR i´m counting a variable "lastbuf" to save the last processed descriptor! Depending on "lastbuf" i write the Completion Pointer Register and write word 2 & word 3 of the descriptor new. This method run´s for a while but ends at once! And Rx-ISR is never executed!

So my question: How can I implement a RX queue with 3 descriptors in a safe mode?

Thanks!

  • I moved your thread to the device forum. They are more familiar with EMAC peripheral.

    Todd
  • Hello Sebastian,

    Having loop of descriptors is not correct way as it would lead to host error due to ownership bit not correctly set.
    In your set up when packets starts arriving at little high data rate feeling all buffers and clearing ownership bits in the descriptors which were set to HW owned by SW before submitting packets.
    Now due to (1->2->3->1) HW will find ownership bit in the 1st descriptor not set and will flag host error interrupt which is unrecoverable error.

    Correct way is to remove loop and let HW halt when it reaches end. SW will process buffers and re-submit descriptors to HW and restart transfer.

    Why are you restricted to 3 descriptors only? You can use internal memory to store descriptors.
  • Hi Prasad,

    I´m not restricted to 3 descriptors, but this was my first beginning! Now I´m using 256 RX-Descriptors without Ownership-Bit used! Setting Bit RX_OWNERSHIP in DMACONTROL Register! This way seems to be a possible solution!?

    But in your suggestion you have single descriptors or an ending queue like 1->2->3-> stop and start at descriptor 1 again?

    Regards, Sebastian
  • Hello Sebastian,

    When you implement 1->2->3->4, you are assuming that you will never reach scenario where all 1, 2, 3 packets will come in burst. Though as you are allocating 256 buffer descriptors and if your n/w traffic is less, you may not reach this condition initially but for long run there is always possibility. For ex- On a gigabit network assuming packet size to be 1500 bytes you get around 87381 packets/second.

    By implementing 1->2->3->stop -> SW process 1,2,3-> Submit 1,2,3 back to hardware you are making sure that your data is not replaced.

    Now if you sure about your data rate and don't want to use buffer descriptor ownership mechanism (or you dont care if data is replaced), to implement 1->2->3->1 you can keep using  RX_OWNERSHIP bit in DMACONTROL (setting it to 1), but make sure that software and hardware is not accessing the buffer at the same time as i see that as only possible reason for crash.

    When you see crash in what is value of RX_CP and RX_HDP in EMAC register? Also when you say it ends after a while is it crash or packet processing stops?

  • Hi Prasad,

    my current solution works fine for my data-rate! (about 50 Mbit/s) 

    But software drops packets when data rate is much higher! How can I manage a data rate nearly 1 GBit/s? So if I understand your post, it´s the better way to have X descriptors in a queue and after processed last buffer descriptor start the queue again and again! So will packets go lost??

    Thanks

  • Hello Eric,

    I was assuming that due to RX_OWNERSHIP bit the packets will get replaced but as I dig further into use of RX_OWNERSHIP setting in the DMA_CONTROL register, this will be used only to avoid software setting the ownership bit. So ignore my earlier observation of 1's packet data being replaced in case of 1-2-3-1.

    So with both ownership bit set by HW or SW packets will get dropped if CPU is not capable of processing at higher data rate. There are other features like interrupt packing, threshold interrupts you can use to handle busty traffic.