0-length UDP payload

[norumwe12]

I've written a Vivado block design wrapper and driver to use this firmware to provide very lightweight UDP I/O to MicroBlaze applications. One minor issue that I can't seem to get working is handling UDP packets with 0-length payload. The stack would have to perform a header transaction (rx_udp_hdr_valid or tx_udp_hdr_valid) but no transaction on the payload AXI stream -- acknowledgement of the header would mark the completion of the packet handling. Is there some trick that I'm missing?

[alexforencich]

Zero length operations are currently not supported. I suspect that the "best" method may be to generate an AXI stream transfer with a tkeep of all zeros, but I have not looked in to this further, and I think the changes to handle this case could be somewhat extensive.

[norumwe12]

Thanks for the quick reply. It's certainly a corner case that probably doesn't justify the effort to support. In the same vein, what are your thoughts on the difficulty of adding ICMP PING support?

[alexforencich]

ICMP support is certainly doable. I just haven't bothered implementing it because I'm not sure it's worth the additional logic just to be able to ping the board. TBH, it might make sense to try to "peel off" components like ARP and ICMP into a separate, lower performance module, perhaps even a soft core, which could reduce the logic resource overhead of such protocols.

[norumwe12]

Adding soft core support for this sounds like an interesting option, especially for my applications that already have a soft core support wrapper around the verilog-ethernet firmware. I’ll poke around a little and let you know how I fare. My applications are for FPGA instrumentation for particle accelerator controls and diagnostics. The network folks like to use Nagios to ping devices to monitor hardware presence and network health which is why ICMP ECHO is something I’d like to provide. Thanks again for making this available!

On Aug 25, 2022, at 4:12 PM, Alex Forencich ***@***.***> wrote: ICMP support is certainly doable. I just haven't bothered implementing it because I'm not sure it's worth the additional logic just to be able to ping the board. TBH, it might make sense to try to "peel off" components like ARP and ICMP into a separate, lower performance module, perhaps even a soft core, which could reduce the logic resource overhead of such protocols.

— Eric Norum ***@***.***

[norumwe12]

I added ICMP ECHO support to the ‘Arty' example by picking off values from the rx_ip_xxxxx nets and driving values back to the tx_ip_xxxxx nets. The very clean way you’ve provided hooks at various levels of the stack made this easy. Enabling ICMP ECHO support for ping payloads up to 64 bytes adds 149 flip-flops and 127 LUTs plus 8 LUTRAMs. I then made the same changes to my UDP to AXI wrapper. I’ve been running a MicroBlaze server providing UDP command/response to an OS X client as fast as possible (~5000 commands and responses per second) while simultaneously issuing PING requests at 10 Hz for about a day now with almost no packet loss so I’m guessing that the multiplexing between the UDP and raw IP inputs is doing the right thing with my simple-minded approach.

On Aug 25, 2022, at 4:12 PM, Alex Forencich ***@***.***> wrote: ICMP support is certainly doable. I just haven't bothered implementing it because I'm not sure it's worth the additional logic just to be able to ping the board. TBH, it might make sense to try to "peel off" components like ARP and ICMP into a separate, lower performance module, perhaps even a soft core, which could reduce the logic resource overhead of such protocols.

— Eric Norum ***@***.***