& cplSiteName &

Is Your Processor a Jet Engine?

Craig Matsumoto
9/29/2010

6:00 AM -- SAN JOSE, Calif. -- The Linley Tech Processor Conference, hosted by The Linley Group , featured a multicore vs. network processor "smackdown" on its agenda Tuesday. Who could resist that?

Obviously, there wasn't any physical smacking down; this was a panel of semiconductor guys who probably all know each other. But they did exchange some verbal blows on a couple of fronts, particularly software.

One of the biggest arguments in favor of general-purpose microprocessors -- things like the Intel Corp. (Nasdaq: INTC) x86 architecture -- is that there's a large population of software engineers who can program the devices. Network processors (specialty chips intended for handling packets) tend to require some specialized knowledge.

"There's a huge software base out there, and when you talk to any serious software developer, they don't want to have to get used to yet another instruction set," said Dac Pham, director of processor cores and development platforms at Freescale Semiconductor Inc.

That's an outdated argument, countered Niel Viljoen, CEO of Netronome : "If we take the argument [back to] the 1920s, we would have internal combustion engines, and when somebody would come up with a jet, we would say, 'No, all our technicians are trained on internal combustion engines.' "

He came up with that analogy on the fly, and it's not perfect. (Pham pointed out that you don't put a jet engine in a car, not safely, anyway.) But being part of the network processor camp -- Netronome is continuing the life of Intel's IXP2800 product line -- Viljoen naturally believes there are tasks best suited for those devices.

As for the software issue, Netronome has prefab libraries that let users avoid getting elbow-deep in code.

The real panel consensus was that a combination of the chip types is usually required. Viljoen conceded that point early on.

In fact, another Netronome representative, director of product management Daniel Proch, had expanded on that point earlier in the day, describing an architecture that uses network processor cores first, then hands off certain tasks to general-purpose processors. The reasoning had to do with the nature of packet flows. I'm hoping to write it up as a separate entry.

— Craig Matsumoto, West Coast Editor, Light Reading

(3)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Pete Baldwin
Pete Baldwin
12/5/2012 | 4:22:18 PM
re: Is Your Processor a Jet Engine?


Here's a separate side to that software argument.  Later that day, I moderated a panel of OEM experts -- engineering leads from systems companies -- and they were adamant that software is the biggest source of headaches, more so than hardware choices.


It's very difficult for a systems company to leave its code behind for the sake of a new architecture.

Pete Baldwin
Pete Baldwin
12/5/2012 | 4:22:17 PM
re: Is Your Processor a Jet Engine?


> So, what is the argument?  That a CRS-1 should use x86 processors to forward packets?


Sort of. But not that seriously.


Part of the point of the discussion was to see if multicore processors, given their increasing abilities, can square off against NPUs.  It's a market the multicore guys have at least a passing interest in.


But the consensus seemed to be that you need both processor types -- so for now, I think they mostly agreed with you.

paolo.franzoi
paolo.franzoi
12/5/2012 | 4:22:17 PM
re: Is Your Processor a Jet Engine?


Time out....


There are some tasks in the forwarding plane that basically require Hardware or an NP to obtain any kind of reasonable price.


The x86 line is really a control plane thing.


Never the twain shall meet in the high performance realm.  In the LOW performance realm, you can turn any multiport Linux computer or Windows PC into a router.


So, what is the argument?  That a CRS-1 should use x86 processors to forward packets?


If your tool is a hammer, then all the problems look like nails.


seven

More Blogs from Craig's A-List
If there isn't a master plan behind Google's creation of Kubernetes, maybe there ought to be.
Already replaced as CEO, John Chambers is fully detaching as he plans to step down as Cisco chairman, truly ending his time as the face and voice of the company.
The network must be automated. And Light Reading must write about it.
Comcast joins Google in asking for a flexible-rate optical standard, rather than 400G or terabit, but that's easier said than done
Cisco, Juniper and other more traditional Interop speakers might get overshadowed by the forces of virtualization
Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events
Partner Perspectives - content from our sponsors
Sports Venues: Where 5G Brings a Truly Immersive Experience
By Peter Linder, 5G Evangelist, North America, Ericsson
Multiband Microwave Provides High Capacity & High Reliability for 5G Transport
By Don Frey, Principal Analyst, Transport & Routing, Ovum
All Partner Perspectives