Intel Isn't Through With NPUs

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 2 / 2

jmunn 12/5/2012 | 3:03:34 AM

re: Intel Isn't Through With NPUs My company tried an Intel NPU, gave up and did the function for less $ than the cost of the ram hanging on the NPU.

It is now practically impossible to discuss doing an NPU development.

The NPU marketing people admit that "Network Processor" has almost become a dirty word.

I work for a medium size company and we are still unlikely to outsource to a third party support company. What do you do when you need to change the features or migrate it? If you outsource it won't the competition be able to do the exact same thing for less money when the third party company sells it to them?

The in house software teams tend to be small and the timelines are short so developing all the NP SW elements from scratch the Intel way is a non starter.

They need a serious open source system of pre optimized SW components that the OEMs can get rolling with e.g. classification, policing, modification, TM, queuing, scheduling, WRR, WFQ etc. This could get them closer to being able to compete against Agere which has most of that stuff built into the HW.

My other problem is board space. I do not have room for the 4-6 memory buses that some 4-5Gbps NPs require.

There seems to be a growing number of low end "packet processor" devices that don't look so much like NPs but do similar functions.

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 3:03:33 AM

re: Intel Isn't Through With NPUs If you write code in C plus intrinsics and use the right programming model such as run-to-completion, the code will be easy to port in the future.

As for programming for DSP, 10% of code (assembly) has to be rewitten anyhow.

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 3:03:33 AM

re: Intel Isn't Through With NPUs If a company implements the traffic management features, normaly it offers multi-chip solution. For example one NPU doing parsing and classification and the other doing TM.

If you have board space issues with one NPU, how could you handle a multiple-chip configuration?

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 3:03:32 AM

re: Intel Isn't Through With NPUs I doubt OEM has enough manpower to try every NPU solution since the architecture is so different. For example, switching thread takes 1 cycle (dealy slots are filled) on Intel NPU but it takes more tha 10 cycles on C5. Therefore lateny hiding techniques will be dramatically different on these two architestures.

Agere only solves a part of the equation in terms of NPU programming, i.e., packet parsing. Since L2/L3 protocols are not difficult to parse, it is not a big deal to develop such code in C.

None of NPU vendors provides good programming model yet and it is essential to write programs on this type of multi-core and multi-threaded architectures. Hope NPU companies will do more to address this issue.

Reply | Post Message | MESSAGES LIST | START A BOARD

swconsult 12/5/2012 | 3:03:32 AM

re: Intel Isn't Through With NPUs None of NPU vendors provides good programming model yet and it is essential to write programs on this type of multi-core and multi-threaded architectures. Hope NPU companies will do more to address this issue.

I think the solution to some of the NPU vendor problems is to go to some of the not-quite-an-NPU solutions. The Cavium chip, for instance, is a bunch (16!) of MIPS64 cores with some special hardware around them.

No, there's no snazzy threading stuff there, but with decent raw performance in the underlying, I'm not convinced that threads buy you anything but pain. IXP2800 microcode is a bear to write.

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/5/2012 | 3:03:30 AM

re: Intel Isn't Through With NPUs Depends on which layer of networking applications NPU will be applied onto.

At L2/L3, latency hiding is essential and Cavium chips are inappropriate. At L7, Cavium chips might have a chance. However the chips were not taped out yet and we need to wait and see what kind of raw performance the chip will offer.

By the way even programming 16-MIPS cores requires a memory consistance model. I am not sure Cavium offers any good solution yet.

Reply | Post Message | MESSAGES LIST | START A BOARD

swconsult 12/5/2012 | 3:03:26 AM

re: Intel Isn't Through With NPUs I'll go out on a limb and say that at L2/L3, ASICs are quite sufficient for most needs.

There are samples out there now, so they're well past tapeout, I'd say. The experiments I've heard about so far look pretty promising for serious data rates and high-level processing.

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 2 / 2