Yes, this is about building a small hashtable in the RAMs internal to the FPGA. As you pointed out, things would slow down a bit if you had to go to external RAM.
However, if you are building a hashtable in external RAM that is accessed via Ethernet, I think there are still some performance gains to be had with an FPGA compared to a non-specialized device.
For one, you get to skip the PCIe bus with an FPGA, reducing latency, since the Ethernet transceivers go straight into the FPGA fabric. Also, while I don't know a lot about power consumption, I expect it would be a fair bit lower on a dedicated FPGA compared to a server performing the same work.
I'll have to think about that one. TBH, this stuff is pretty difficult to reason about.
However, I can say that I used a SMT solver as part of the wonderful SymbiYosys verification flow to verify that the design was good for around 20 cycles, no matter what the inputs are. That, and the randomised testing gives me quite a bit of confidence in the design.
The SRAM clock and the Ethernet clock can be independent. The SRAM clock rate is what determines the rate of lookups for a single cuckoo hashtable.
On a modern FPGA, the SRAM clock can run up to about 500MHz. So, if you pipeline things, you can get 500 million lookups per second in the FPGA fabric. The maximum packet rate in 10G Ethernet is around 15 million/sec. So, no matter how you design the protocol you use to communicate with the FPGA, if you only request a single lookup per packet, you will be well below the maximum rate the RAMs can support.
Of course, I haven't actually built any of this. The clock rates in the blog post are much lower, and the chip is much smaller. So, this is all an educated guess.
Yes, benchmarks are missing. When I wrote this almost two years ago, I just wanted to explain the design at a high level to make it easier for people to understand the code. I didn't have access to a higher end FPGAs capable of 10G+ line rates to do any serious benchmarking, nor did I have access to precise Ethernet timestamping equipment.
However, I do have a bit of experience designing low latency FPGA based networking firmware. <100 nanoseconds measured wire to wire at the Ethernet level should be possible with 10G Ethernet. That's actually quite a long time on an FPGA. But, when you have latencies on the order of packet (de)serialization times, you need to be very careful about what you are measuring.
Also, I haven't actually built what I'm describing, so take my estimates with a grain of salt.
Yes, but it would be if implemented on an FPGA with 10G capable transceivers. The hashtable is capable of looking up a key every clock cycle so it is actually capable of a fair bit more than 10G for lookups.
However, if you are building a hashtable in external RAM that is accessed via Ethernet, I think there are still some performance gains to be had with an FPGA compared to a non-specialized device.
For one, you get to skip the PCIe bus with an FPGA, reducing latency, since the Ethernet transceivers go straight into the FPGA fabric. Also, while I don't know a lot about power consumption, I expect it would be a fair bit lower on a dedicated FPGA compared to a server performing the same work.