Re:Liberouter Combo Cards – FPGA boards focused on network d...
by wtallis on Wednesday December 07, 2016 @12:00PM
(#13124010)
> What you want to avoid is buffering ("bufferbloat").
Excess buffering is a problem, but a little bit is fine unless you're trying to do high frequency trading. If you don't move packets to an external DRAM, you're in no danger of having bloated buffers with just the memory on the FPGA.
Or you could implement an active queue management algorithm to keep your buffers from inducing too much unnecessary latency even when they are generously sized. There are a bunch of AQMs out there to pick from, of varying complexity. And it doesn't seem like there's near enough research into hardware implementations suitable for use in switches or network co-processors.
Letting the OS touch more than a small percentage of the packets would be a gross waste of resources. If you want to write a program to process packets, use a real processor. (Putting an FPGA in a computer and then running a soft core on the FPGA is even sillier for performance.)
The main reason to use an FPGA for this is to build structures that effectively encode your firewall or other layer processing rules in tables in the hardware, so the hardware can make a decision without having to consult the processor. MPLS and VLAN routing is the obvious case, but you can usually keep a short IP routing table in there too. Ideally you'd be able to make this decision early on while recieving a packet so you can start transmitting it while the last bits are still coming in. What you want to avoid is buffering ("bufferbloat").