4 ms·
Or we should stop thinking about processing packets with hardware. Does it still make differences these days? Designing hardware for a single purpose most of t
by alerighi 6y ago
Or we should stop thinking about processing packets with hardware. Does it still make differences these days?
Designing hardware for a single purpose most of the times is not a good idea. That means that you are stuck with the implementation that was implemented in the hardware for a very long period. Also, an hardware implementation can't take into account (and handle) all particular cases, for example malformed packets.
IP was designed to be flexible, you could have in theory used whatever L2 protocol you wanted, and whatever L4 protocol you wanted. Thanks to hardware implementation that considered only Ethernet as L2 protocol and TCP or UDP as possible L4 protocol anything was innovated.
The reason that we are so slow to adopt IPv6, same reason. What would have take to just adopt it if we didn't have hardware implementation of IPv4? Software update and you are done.
The problem is that in the world there are many not so good programmers that write inefficient code and thus people think that they need to implement things in specialized hardware to make them faster. You don't, at least in most cases.
- knorker 6y agoI could be wrong, but I would think high packet rates with large routing tables (default-free zone) would still need a TCAM.
- kazen44 6y agoAlso, hardware based offloading is a godsend for reliability aswell. You can upgrade the control plane of a router with traffic still flowing thanks to the data plane being seperate. You can even make another router do control plane for the data plane in another router. Not to mention the massive performance benefits.
- kevingadd 6y agoSoftware packet processing simply does not scale to the levels that hardware packet processing does, and that's not even mentioning the cost issues involved in provisioning and operating enough CPUs to do it. Maybe in a few years now that we're seeing higher core counts become common in non-server hardware...
- sleepydog 6y agoWithout knowing how hardware forwarding engines work at any kind of detail, I would be wary of throwing more cores at this kind of problem, because you would need to decide how to divide up your work between cores. You could use a 5 or 3-tuple flow hash, but then you're limiting the speed of a single connection to what a single core can do. And if you use any other way to divide up work, you're bound to get out-of-order packets which kills TCP performance.
- zamadatix 6y agoFor $10,000 you can get a box which can route 12.8 Tbps (25.6 Tbps bidirectionally) at 256 byte packet size. Even putting all of that money at literal CPU alone (i.e. not the rest of a server or interfaces) you can't route at that performance, let alone match the feature set of the hardware before talking about extra things one could add in software that would slow it even more.
- elktea 6y agowhat box is that?
- insaneirish 6y agoBroadcom Tomahawk III, as an example: https://www.broadcom.com/products/ethernet-connectivity/switching/strataxgs/bcm56980-series https://www.broadcom.com/products/ethernet-connectivity/swit...
- insaneirish 6y ago> Or we should stop thinking about processing packets with hardware. Does it still make differences these days? Yes, yes it does. CPUs will never catch purpose built chips for networking. Networking chips are getting more programmable, though. The most known effort is P4 (https://p4.org https://p4.org). Even for vendors that don't support P4, they are still internally making their hardware more fungible, which is good. > The reason that we are so slow to adopt IPv6, same reason. IPv6 has been slow to adopt because it solves a problem most people have not had, in an overly complicated way.
- JustFinishedBSG 6y ago> Does it still make differences these days? Have fun routing several Tb/s of traffic without dedicated ASICs....