alexforencich

These things are probably the best bang for your buck right now.

The ex-Alibaba KU3P boards are available for under $200, although you do need a separate JTAG cable with flying leads to load designs on them. I recommend starting with that. I'm building the next-generation version of Corundum on those boards, at least initially. I will certainly be adding support for Alveos and such in the near future. As far as adding functionality, it depends on what you want to do, but in general you should expect to have to do a fair amount of tinkering with the design.

I'm using some very cheap (~$200) ex-Alibaba FPGA boards for the initial development of the next-generation version. They have 8 lanes of PCIe gen 3 and two SFP28 capable of operation at 25 Gbps. Honestly that's pretty hard to beat. Support for other boards will be added in the near future. The new library will also include a new IP stack called Zircon, which supports UDP, among other things.

The plan for corundum-ng is to support 400G, but it will be a while before this is available.

A hammer, perhaps?

The graph above that one is totally wrong. The frame overhead graph may be correct, though.

Ah yeah, that's probably true. According to some back of the envelope math, it seems like the distribution should be more like 5%, 1%, 1%, 3%, 50%, 39%, ignoring the first and last size bins.

I think the author may have made a mistake in some of the math. The frame size distribution plots are likely based on the number of frames, not the amount of data contained in said frames. The 1500 byte and other large frames should therefore account for the lion's share of the actual data transferred. Correcting this error will totally change the final two graphs.

Well, we're planning on porting Corundum to the NetFPGA SUME hardware at some point in the near future. Should be relatively straightforward as the PCIe interface on the Virtex 7 is the same as on the Ultrascale parts.

NetFPGA does have a NIC reference design, but AFAIK it's just the Xilinx XDMA core connected to a Xilinx 10G MAC. No accessible transmit scheduler, no offloading of any kind, etc. Just about as spartan as you can get, and it's built from completely closed components so you can't really make many modifications to it.

For what we're doing, we can't use any existing commercial NICs or smart NICs because they can't provide the precision we need in terms of controlling transmit timing. We don't care about EBPF, P4, etc. We care about PTP synchronized packet transmission with microsecond precision.

Netronome cards are a gigantic PITA to program, and they are not capable of the precise timing that we need.