4 ms·

this isn't 10Gbit.

adam_walker 3y ago
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.
- thethimble 3y ago
  > The hashtable is capable of looking up a key every clock cycle Does the SRAM latency still allow for single-cycle reads at 10G?
  - adam_walker 3y ago
    Yes. My comment above glosses over some details. 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.
  - rowanG077 3y ago
    For sure! 10G can be done on FPGA's at 312.5 Mhz using 32-bit words. BlockRAM on higher ended chips reaches 450Mhz+. If you wanted to it could even run at 156.25 Mhz with 64-bit words. This way it is even doable on lower ended FPGA's.
pjc50 3y ago
This is the 100Mbit PoC for an idea that clearly scales to 10G if you buy an expensive enough FPGA.
- le-mark 3y ago
  This write up seems to only refer to on fpga ram which is fast, but very limited. In fact the author seems to completely ignore using any ram external to the fpga. Certainly fpga have capacity to interface with DDR ram of various types, and the more expensive fpga the better, but that also impacts the performance quiet a lot, making performance more in line with a normal non specialized device; beacause memory access time dominates.
  - pjc50 3y ago
    > making performance more in line with a normal non specialized device; because memory access time dominates. Well, yes. With a short enough piece of network cable it's probably lower latency to query a different one of these devices a short way away than wait for DRAM to very slowly charge up a row.
  - adam_walker 3y ago
    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.

this isn't 10Gbit.

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.

thethimble 3y ago
> The hashtable is capable of looking up a key every clock cycle Does the SRAM latency still allow for single-cycle reads at 10G?
- adam_walker 3y ago
  Yes. My comment above glosses over some details. 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.
- rowanG077 3y ago
  For sure! 10G can be done on FPGA's at 312.5 Mhz using 32-bit words. BlockRAM on higher ended chips reaches 450Mhz+. If you wanted to it could even run at 156.25 Mhz with 64-bit words. This way it is even doable on lower ended FPGA's.

pjc50 3y ago

This is the 100Mbit PoC for an idea that clearly scales to 10G if you buy an expensive enough FPGA.

le-mark 3y ago
This write up seems to only refer to on fpga ram which is fast, but very limited. In fact the author seems to completely ignore using any ram external to the fpga. Certainly fpga have capacity to interface with DDR ram of various types, and the more expensive fpga the better, but that also impacts the performance quiet a lot, making performance more in line with a normal non specialized device; beacause memory access time dominates.
- pjc50 3y ago
  > making performance more in line with a normal non specialized device; because memory access time dominates. Well, yes. With a short enough piece of network cable it's probably lower latency to query a different one of these devices a short way away than wait for DRAM to very slowly charge up a row.
- adam_walker 3y ago
  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.