How can this happen? (ethernet library client queue)

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

How can this happen? (ethernet library client queue)

Post by DemoniacMilk »

Since two days I am running into a weird problem when using the ethernet library and one client.
Sometimes, the ethernet funtionality works fine, sometimes it does not work at all.

I added a ton of xscope outputs:
Eth_client_queue_full.PNG
(5.4 KiB) Not downloaded yet
Eth_client_queue_full.PNG
(5.4 KiB) Not downloaded yet
and it seems like the clients fifo/queue of size n is full once n-1 packets have been received and does not recover from that state. This behavior might or might not occure when starting a new debug session.

But how can this happen?
The library should not be forwarding any packets to the client before the client has set its configuration using the ethernet config interface (correct?). In my case, I have slightly altered the ethernet library, specifically the hash mac address filtering. I added a variable/flag that allows a client to bypass the MAC filtering, resulting in all packets being given to the client. The flag is set by calling the give_all_packets() config interface function.

Code: Select all

    // get the tasks RX client index and let CFG know that we want all unused packets
    unsigned uiIndex = ethRx_if.get_index();
    // Let us receive aaaaaaall the packets
    ethCfg_if.give_all_packets(uiIndex);

   while(1){
        select {
           case ethRx_if.packet_ready():
                unsigned char ucaBuffer[ETHERNET_MAX_PACKET_SIZE];
                ethernet_packet_info_t packetInfo;
                ethRx_if.get_packet(packetInfo, ucaBuffer, ETHERNET_MAX_PACKET_SIZE);
                // process the packet
                break;
From here on, I dont see how the clients queue can be filled permanently, as the application above should grab an ethernet packet on receiveing the packet_ready() notification. The queue might be full if packets are received too quickly, but even then, there should be a packet added to the client queue whenever the client has processed another packet.


peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Post by peter »

Can you let us know what version of lib_ethernet you are using. It would be good to know if this might be an issue which has already been resolved.
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

I used lib_ethernet 3.1.2
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Post by peter »

Would you mind trying lib_ethernet 3.2.0? It is only currently available through github.com, but has some critical fixes in it.

If it does fix this issue for you then we can try to get it onto xmos.com ASAP.

Regards,

Peter
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

I'll do that but might take some time, as I have to readd the functionalities i added to the previous version.
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Post by peter »

A quicker option then might be to apply the lib_ethernet patch between 3.1.2 and 3.2.0. I've attached the relevant bits I got by doing:

Code: Select all

git diff -p -r bc21703 -r b5c053c
As long as you are using git for your lib_ethernet work you can try applying it using:

Code: Select all

git apply lib_ethernet_patch.txt
Regards,

Peter
Attachments
lib_ethernet_patch.txt
(8.85 KiB) Downloaded 171 times
lib_ethernet_patch.txt
(8.85 KiB) Downloaded 171 times
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Thanks a lot, but unfortunately we dont have git here.
peter
XCore Addict
Posts: 230
Joined: Wed Mar 10, 2010 12:46 pm

Post by peter »

If you're using unix/osx you can apply the patch with:

Code: Select all

patch -p1 < lib_ethernet_patch.txt
DemoniacMilk
XCore Addict
Posts: 191
Joined: Tue Jul 05, 2016 2:19 pm

Post by DemoniacMilk »

Unfortunately im using win10.

I have manually adjusted version 3.2.0 but the problem remains: It may or may not work.
Eth_client_queue_v320_worked_not.PNG
(7.5 KiB) Not downloaded yet
Eth_client_queue_v320_worked_not.PNG
(7.5 KiB) Not downloaded yet
Eth_client_queue_v320_worked.PNG
(4.33 KiB) Not downloaded yet
Eth_client_queue_v320_worked.PNG
(4.33 KiB) Not downloaded yet
When setting ETHERNET_RX_CLIENT_QUEUE_SIZE > RGMII_MAC_BUFFER_COUNT_RX / 2 + 2 (client queue bigger than low priority slots available in the buffer), the result is
Eth_client_queue_v320_drop_lp.PNG
(6.61 KiB) Not downloaded yet
Eth_client_queue_v320_drop_lp.PNG
(6.61 KiB) Not downloaded yet
and the ethernet client thread (bridge) does receive packets.
Post Reply