Regression with Etherbone/LiteScope and PacketFIFO?

[enjoy-digital]

https://libera.irclog.whitequark.org/litex/2021-10-20#31037395;

[mdejw]

I can confirm regression using code similar to udp streamer with streaming out data packets with about 512 bytes with interval about 1.2ms. (trenz_c10lprefkit board)

I see on wireshark ARP requests form FPGA board, that are coming just after there is sent back back ARP response. In this state there are also no responses to ping.

[enjoy-digital]

Hi @mdejw,

thanks for the feedback. If you have time, could you see if you still have the regression with #94 merged?

[mdejw]

I've checked with #94 merged, but the result was the same.

It seems my problem is connected with ICMP - if on host no one is listening for UDP packet, host sends back ICMP packet with "destination unreachable/port unreachable" with payload of received UDP packet.

If I disable ICMP support, or receive UDP traffice on host( so, no ICMP "port unreachable" are generated from host side) or switch to pre PacketFIFO commit on liteeth, I see no lock situation.

The lock appears after two ICMP packet with "destination unreachable/port unreachable" are sent to target:
The lock seems to appear after the sequence of packets:

• ARP request from target
• ICMP Destination unreachable/port unreachable from host
• ICMP Destination unreachable/port unreachable from host
• ARP reply from host

[michael-betz]

Very interesting! I think I'm running into this as well with the following setup:

• Kintex7 (meets timing easily)
• No CPU core
• Etherbone to access some CSRs
• Using LiteEthUDPIPCore to stream about 20 MB/s over an UDP port from FPGA to PC

On the PC side I'm receiving the stream with netcat.
This works initially but usually breaks pretty quickly if I hit the FPGA with a flood ping (sudo ping -f <IP>).

It breaks in the same way as described by mdejw ... the FPGA starts to send ARP requests like crazy and does not respond to pings / etherbone anymore.

I can confirm that this regression got introduced in 2b23788 when replacing SyncFIFO by PacketFIFO.
In fact, I can get things to work reliably, undoing the commit on the current master with:

diff --git a/liteeth/core/icmp.py b/liteeth/core/icmp.py
index e1703dc..4ac2e4c 100644
--- a/liteeth/core/icmp.py
+++ b/liteeth/core/icmp.py
@@ -129,10 +129,11 @@ class LiteEthICMPEcho(Module):
 
         # # #
 
-        self.submodules.buffer = PacketFIFO(eth_icmp_user_description(dw),
-            payload_depth = 128//(dw//8),
-            param_depth   = 1,
-            buffered      = True
+        # Workaround for #86
+        self.submodules.buffer = stream.SyncFIFO(
+            eth_icmp_user_description(dw),
+            128 // (dw // 8),
+            buffered=True
         )
         self.comb += [
             sink.connect(self.buffer.sink),

Haven't digged very deep into the PacketFIFO yet and how it behaves differently from SyncFIFO under these conditions.

Merry 🎄 ☃️ 🎅 🎄

[enjoy-digital]

Thanks @mdejw, @yetifrisstlama, I've reverted to SyncFIFO for now and will have a closer look at the behaviour with PacketFIFO in January.

[enjoy-digital]

The was probably related to this enjoy-digital/litex@edd98c2, which should fix it. I'll do a test soon.