AnsweredAssumed Answered

Packet reordering on LS1043ARDB

Question asked by Thorsten Horstmann on Dec 21, 2017
Latest reply on Sep 10, 2018 by Ali Imran

Hi,

 

we observe massive Ethernet packet reordering on our LS1043 equipped custom board which runs a SDK 2.0 based Linux. To verify this issue is not limited to our design / configuration I have tested this on the LS1043ARDB reference system where I can confirm the same behavior. It can be easily reproduced for example by sending some ICMP packets back-to-back with ping:

 

Host (192.168.137.238): 

$ ping -f -c20 -l20 192.168.137.243

 

LS1043ARDB (192.168.137.243): 

tcpdump icmp | grep request
[ 2765.909316] device fm1-mac9 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fm1-mac9, link-type EN10MB (Ethernet), capture size 262144 bytes
06:43:42.533445 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 1, length 64
06:43:42.533447 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 2, length 64
06:43:42.533452 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 3, length 64
06:43:42.533457 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 4, length 64
06:43:42.533471 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 5, length 64
06:43:42.533471 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 8, length 64
06:43:42.533480 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 9, length 64
06:43:42.533481 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 12, length 64
06:43:42.533488 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 13, length 64
06:43:42.533489 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 16, length 64
06:43:42.533496 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 17, length 64
06:43:42.533498 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 18, length 64
06:43:42.533500 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 6, length 64
06:43:42.533504 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 7, length 64
06:43:42.533505 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 19, length 64
06:43:42.533509 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 10, length 64
06:43:42.533517 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 14, length 64
06:43:42.533518 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 11, length 64
06:43:42.533526 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 15, length 64
06:43:42.533527 IP 192.168.137.238 > 192.168.137.243: ICMP echo request, id 6550, seq 20, length 64

 

As you can see the ICMP request are received out of order. I'm wondering why this happens. I guess it is related to the DPAA queues, but should not the hash algorithm place the packets from one flow in the same queue in this case?

 

I can reproduce this issue with different protocols like raw Ethernet or UDP as well. I understand that none of the protocols guarantees the ordering of the packets. But I'm surprised that this is the default behavior since for most known protocol algorithms these kind of reordering will be handled like packet loss.

 

Can someone help me to understand the root cause of this issue? Is there a way to prevent this reordering?

 

Thank you in advance,

  -Thorsten

 

 

Outcomes