SAN JOSE, Calif. Ė Software tops the list of concerns for network systems developers these days. High on their wish lists are better tools for debugging multicore processors and supporting virtual I/O, according to a panel of engineering managers at the Linley Tech Processor Conference here.
Technical managers from Cisco Systems, Hewlett-Packard's networking division, Juniper Networks and gateway maker Stoke all ranked software support as their chief concern when picking a multicore processor.
"Mostly the software is still lagging to take advantage of latest optimizations," said Raghavendra Mallya, a distinguished engineer from Juniper. "We would like to see [better] virtualization in I/O to create partitioned systems," he added.
"We look a lot at software tool chains" when picking a processor," said Mark Ennamorato a director of engineering for enterprise routers at Cisco. With multicore processors "debugging is very hard--trying to figure out where a packet has gone is quite a challenge," he said.
That's especially true when engineers need to make changes to multithreaded networking applications, said David Sonnier, a processor architect at LSI.
"Partitioning an app into a lot of threads especially for packet processing is a real challenge," said Sonnier, speaking in a separate panel of processor designers.
"If new requirements drive a small change in the app, performance can be cut in half because partitioning of the threads is suddenly incorrect," he said.
David Malicoat, a distinguished architect in HP's networking group, said engineers are making "stair step" progress in supporting virtual I/O in networking systems, another important but thorny software issue. Ironically the growth in the number of processor cores available has helped ease some early problems in load balancing.
"Early dual-core, single threaded processors running two jobs simultaneously often had load balancing problems where one core was unused and another was running flat out," Malicoat said.
The multicore hardware itself is getting powerful enough to make even ASIC giants like Cisco think twice about developing its own chips.
"Unless you are really trying to get to very high performance, there doesn't seem to be much reason to do your own ASIC anymore," said Ennamorato. "I think the scalability is there [in off-the-shelf chips] except for some extreme cases," he said.
However, all sides agreed, OEMs need to evaluate the details of increasingly complex multicore processors closely to find architectural bottlenecks often in memory controllers or how resources are shared. "There are a lot of subtleties," said Ennamorato.
Shifts in memory chips also create major headaches for network systems makers, said HP's Malicoat. "We have had to redesign systems because a specific flash chip we used was no longer available due to consolidation among flash suppliers," he said.
In addition, engineers have faced conflicts synching the life cycle of their networking systems with DRAM generations, Malicoat said. "After shipping a system for a few years, you may have to figure out if you will do a redesign to support a next-generation memory or buy enough of the old memory chips to last the system's lifetime," he added.
He noted that most of the processors presented at the conference supported DDR3 DRAMs. "But DDR4 will be here in 2014, so in three more years we may start to see a crossover," he said.
Virtual I/O is making "stair step" progress, said HP's David Malicoat.