This has been done many, many times. It works extremely well for some applications, but also often becomes an operational nightmare. Let's say that you do manag

This has been done many, many times. It works extremely well for some applications, but also often becomes an operational nightmare. Let's say that you do manage to create a hardware implementation that's fully equivalent to the kernel one at some point in time, even in terms of things like configurability and monitoring. Something that has never happened before AFAIK. Then technology changes, your needs change, or there's a security issue. Now you have to go through a special update process - assuming an update is even available - to keep up. This might not be a problem for a small deployment, but in a small deployment it probably wasn't worth going the specialized route anyway. In a large deployment, anything that doesn't fit into the common update/remediation workflow is going to require special accommodation in code. Is the engineering cost plus the hardware cost worth it to the customer? Sometimes still yes, but more often no. There are many examples of companies who found out the hard way that the market for this kind of thing isn't big enough to recoup their own development and other costs. P.S. This is very similar to the arguments for/against hardware RAID controllers. For whatever reasons, rightly or wrongly, those are also steadily losing popularity. Software really is eating the world. P.P.S. In some cases, e.g. Amazon, the "smart NIC" approach is the common workflow, so the color of this argument changes. OTOH, it's also worth noting that the kinds of network filtering/virtualization/whatever that Amazon does is very specific to them and has nothing to do with any standard. They dedicate staff to support it. Bespoke ASIC/FPGA approaches aren't the same as a market in which you can sell them.