Moore's Law is a well known part of history of Intel.  Lesser known is how that impacts the networking world.  Many of the features of modern Ethernet are offload workloads from the processor(s).  The effect of Moore's law is that the CPU gets faster at doing those workloads at the same rate that the Ethernet controller does.  At Intel, we learned that lesson with our PRO/100 Smart adapter and it really came home with our PRO/100 Intelligent adapter.  These are older 10/100 megabit adapters and they were offloading IPX workloads.  The cards had processors on board to put together IPX data streams and move the data into the memory of the host system.  The PRO/100 Smart came out just as the Intel486™  to Pentium® processor transition was happening.  The 486 and this new thing called PCI bus, really couldn't handle the 100Mb workloads.  The Smart moved the datagram assembly into the coprocessor and things were good (on the early Pentiums at least).  However, as the same cards went into faster buses and faster systems, the net improvements went down.  We upgraded the PRO/100 Smart into the PRO/100 Intelligent with a faster coprocessor and Ethernet controllers (not to mention almost half the size) but things didn't reflect as well as we had hoped.  The Pentium II processor was out and the PCI chipsets had gained significant performance since their introduction.  Even with the coming Gigabit transition, we could see the writing on the wall.  The power of the coprocessor would never be more than the gains of power of the processor via Moore's law.  The data offload would work for one generation, then be made worthless by the next processor.  We looked into making a third generation offload card for the Gigabit generation, but we figured out that within six months of launch, another Intel CPU would come out to remove any performance advantage the offloads created.

Software was already a problem since the operating system likes to control things like the network interface.  When data movement is offloaded from the domain of the O/S, it can take a lot of work with the O/S vendor.  With our IPX offloads, that just meant working with Novell*.  They were very willing partners.  But not all vendors and O/S teams are like that.  Because the code that runs on the coprocessor is closed source, it can have very limited acceptance in open source engagements.  The code on the coprocessor would also be subject to defects that could be harder to fix in the field than a driver issue.  Nobody really likes having to get new firmware.  Not to mention what could happen if an exploit was in the offload code.  With the O/S in charge, the risk of exploits can be limited since the admin can close off ports, or hand patch the exploit.  In the coprocessor model, you are at the mercy of the adapter vendor.  And the only mitigation is to either turn off the coprocessor (which may not always be an option) or remove or shutdown the card.  Not something our customer support people were very happy about having to recommend.

           The return on investment calculation was easy when we looked at it.  Moore's Law would always put our coprocessor to reduced effectiveness almost by the time the card shipped.  The software model was easy on paper, but the realities of O/S vendors, exploit risks and field upgrades made it very complex.  No matter how many we shook the magic 8 ball, all signs pointed to No.

So our IPX offload engine card family ended before the third generation was launched.  We put our efforts into dataflow efficiency and stateless offloads that would provide value no matter the CPU abilities.  This has provided value to our customer no matter what processor goes into it. Fighting Moore’s Law is like fighting the tide. Rather, we took the strategy to ride the tide and use stateless offloads to reduce latency. Today, our strategy has paid off; we have systems that can saturate multiple bidirectional 10 Gigabit links.  


Time to wrap up our history lesson:

1)  Moore's Law means the processor you buy tomorrow will most likely out perform the offload you buy today without allowing enough time to return the extra cost of a coprocessor.

2)  What looks good on paper is often proved less than effective by the real world

3)  Thanks for using Intel Ethernet products.