Designed for Multicore: Enea Message Passing Model

Marcus Hjortsberg, VP of Product Management at Enea explains how the Enea message passing programing model was designed for multicore long before multicore was a emerging trend. 

Demo of load balancing framework on Enea OSEck

Magnus Gille, Director of Product Enablement at Enea demonstrates Enea OSEck and the Load Balanaceing Framework in a video steaming application.  For more Enea videos visit our YouTube Channel

Bob Monkman Explains the Enea/Freescale Strategic Partnership

Bob Monkman, Director of Strategic Alliances at Enea.

Enea Live: More from the Freescale Technology Forum

Right now at FTF Hugh Herr - Athlete, scientist, innovator and futurist, is sharing his story and the technological advances that it inspired with his speech titled "Technology and the Human Spirit: Merging Body and Machine."  Hugh lost his legs to frostbite in a climbing incident - but that has not stopped him from attaining his goals.

Today Enea has a number of sessions including two from Daniel Forsgren:

Heterogeneous Computing from the RTOS Perspective
Daniel Forsgren, System Architect will talk about how increasing performance demands are driving the evolution of application specific hardware. We examine the OSE family of real-time operating systems in combination with Freescale's QorIQ processors and StarCore DSPs as the foundation for an effective, efficient and very powerful solution for heterogeneous systems.

Message-Passing in the OSE RTOS Family - Design Principles for Multicore Applications
Daniel Forsgren, System Architect takes an in-depth look at the OSE message passing concept and how it be used as foundation for both inter-process and inter-processor communication. We examine the fundamentals of OSE signaling, with code examples and performance figures for the Freescale MSC8156 multicore DSP.

Enea Live: News from Freescale Technology Forum

Today, Enea made two major anouncements from FTF regarding support for the latest multicore communications processors from Freescales - as well as support for the recently released Freescale AdvancedMC base station reference design.

Enea Supports Freescale 64-bit e5500 technology and newest QorIQ^TM Communications Processors 

Highlights:

1. Enea will offer comprehensive software support for Freescale Semiconductor's new 64-bit e5500 core.

2. This includes the 64-bit P5020 and P5010 products and 32-bit P3041 device.

3. Enea's offerings will be focused on Enea OSE® Multicore Edition, its hybrid realtime operating system that supports the widest range of multicore processing models and the Enea® Optima tools suite optimized for developing, debugging and optimizing multicore systems.

4. In addition, Enea offers a comprehensive set of complementary software including high availability, data management and network protocols.

5. The combination of Enea software and Freescale's latest multicore communications processors provide a highly integrated and powerful platform for telecom equipment manufacturers to build next generation equipment including high performance routers and switches, Long Term Evolution (LTE) radio access nodes and radio network controllers.

Enea Delivers Complete Software Package for Freescale Base Station Reference Design

Highlights:

1. Enea is delivering a complete software package for a recently released Freescale AdvancedMC^TM (AMC) base station reference design.

2. The reference design features a powerful multicore processing package based on Freescale's MSC8156 DSP and QorIQ^TM P2020 technologies.

3. As the only company with a software solution that spans from DSPs to multicore CPUs, Enea is uniquely qualified to help developers of advanced base stations harness the power of this new integrated board enabling rapid development and deployment.

4. Enea's offering includes the Enea OSE® Multicore Edition for CPUs; the DSP-optimized version of OSE - Enea OSE®ck; Enea® dSPEED, a suite of management, debug and error handling services for multicore DSPs; Enea® Hypervisor, Enea® LINX, a scalable interprocess communications (IPC) layer and Enea® Optima Eclipse based tools for developing, debugging and optimizing multicore systems.

5. All Enea technology is based on a consistent software architecture and the same easy to use, but powerful message passing programming model. This accelerates development, integration and debugging of highly reliable and performance critical applications, resulting in clear competitive advantage for telecom equipment manufacturers.

 

 

 

Enea Live: From The Freescale Technology Forum

Enea is live from The Freescale Technology Forum in Orlando, FL today.  FTF is Freescale Semiconductor's major ecosystem event bringing together customers, partners and editors in one place. 

Right now Freescale Chairman and CEO Rich Beyer is kicking off the first major session with his keynote address.   

As a top-level Global Diamond Sponsor, Enea has a major presence at the show.   Today we are joining and leading several sessions including:  

A Visionary Look into the Future of Embedded Multicore Operating Systems

Patrik Strömblad, Chief System Architect, OSE will take a visionary perspective on what role the RTOS will play in a multicore future. As we will discover, there may be several good reasons to question conventional operating system principles going forward. A case study based on Enea OSE® on Freescale's P4080 will be presented.

Multicore and the Convergence of Control Plane and Data Plane

Michael Christofferson, Director of Product Management will propose a single software architecture for multicore that simultaneously satisfies requirements for all use cases including such issues as: a) legacy migration issues, b) scalability - performance and implementation, and c) security and fault management.

Introduction to Enea Products

An introduction to a core set of multicore platform software solutions from Enea for Freescale processors and DSPs.

Panel Presentation: Virtualization Technology from Low-Power Dual-Core to High-Performance Eight-Core Solutions and More

Magnus Karlsson, Senior Member of Technical Staff will join this panel to discuss the trends and technologies for virtual multicore platforms for various market segments

Is Anyone Really Using Multicore?

I was asked this question by a colleague and couldn't really come up with a straight answer. Are people using multicore? What is multicore? What defines if you are using it or not?

From my perspective there is more than one answer to the questions. One answer is that a multicore chip is just a bunch of cores, unrelated to each other. Another case of multicore is a symmetrical cache coherent chip where the cores are very much aware of each other. What and how you use it all depends on your use-case and what you are trying to achieve. There is no simple one stop with one solution that fits all.

There are some projects where all we want to do is take two or more processors and combine them on one multicore chip. This is the typical bill of materials reduction project, the product already exists and all the effort is just spent on making a cheaper version with the same capabilities. The typical device here would be a dual core PowerPC replacing two older processors. In this scenario the software is typically running asymmetrically (AMP) oblivious to the other cores.

In the data processing applications there is a strong trend towards multicore. Let's look at two fields. In signal and speech processing applications, DSPs are still the reigning champions but they are seeing more and more competition from general purpose processors. A few years ago we started seeing the first combinations of ARM cores and DSPs, now we see the combination of multicore ARMs and multicore DSPs on the same chip and on some chips the ARMs are taking over completely with the help of accelerators. In IP packet processing applications the general purpose processor is still king, but here we can also see a strong growth of cores. Both of these applications have a high degree of parallelism and are very well suited for multicore devices and therefore these domains are completely owned by multicore chips today. There is however a big difference in their execution environments. The DSPs typically use a homogeneous OS/RTOS environment; sometimes they even do that when the architectures are different. But the IP packet processing applications almost exclusively use a homogeneous hardware environment with a heterogeneous software environment with Linux on one or more control cores and something else on the application cores.

On the pure control plane processor the situation is somewhat different. It is similar to the first case where we are trying to reduce the number of processors in the system, but here we often also want to increase the processing capability and use the fact that the cores come closer together and can execute programs in parallel. The trend here is clear; most new processors are multicore processors but with fewer cores than those aimed at pure packet processing. The up-side is that they are more powerful. The reigning software model is definitely symmetrical multi processing (SMP) with one OS running on all the cores at the same time. 

I see multicore taking over on almost every corner of the industry and I think the question should really be "who isn't using multicore?"

Magnus Gille is Director of Product Enablement at Enea

 

Enea Releases Open Source Tool for Analyzing Java Deadlocks

by Ulrik Svensson

Threads are difficult. In every multi-threaded project I've been involved in, I've seen issues with deadlocks and data races. Getting it right tends to be a real challenge even for experienced developers.

After seeing these kinds of issues over and over again I started thinking about what can be done to avoid them or at least how to find them while testing. But deadlocks are difficult to catch with conventional testing and trying to verify all possible thread interleavings is usually impossible.

I was searching for existing deadlock related test tools but all I found was papers and academic proof-of-concept code, nothing that could be used for real-world testing. So I decided to invent such a testing tool myself... and it became JCarder.

JCarder is a tool that can find potential deadlocks in concurrent multi-threaded Java programs. It can analyze a program execution and tell whether a deadlock might have occurred if the threads had been scheduled differently. That is, deadlock problems can be found without triggering actual deadlocks while running the program.
 
Here is a simplified overview of what happens when analyzing a program with JCarder:

• First, JCarder instruments the program's byte code so that all lock operations are logged to disk.
• Next, the program continues execution as usual while logging information about its use of locks.
• Finally, when the program has finished execution, JCarder analyzes the logged information to find deadlock problems.

JCarder was initially developed by me and a colleague as an internal testing tool used by Enea, but after Enea decided to release JCarder as open source, we started to receive external contributions and patches from an evolving open source community. Recently, we added support for more advanced filters in order to improve the analysis accuracy. Those patches will be included in the next release.

Documentation, source code and binaries are available here: http://www.jcarder.org

A new release of JCarder is planned soon.

Top 3 Trends in IP Packet Processing Systems: Optimal HW Resource Utilization

by Michael Christofferson

 

Trend 2 - Dynamic Adaptation to Network Traffic for Optimal HW Resource Utilization

Given Trend 1 above - i.e. multi-core devices - the main challenge for adoption of more cores revolves around the "tension" between raw system performance and lowest possible utilization of scarce HW resources which in packet processing systems can be an extreme bottleneck if not handled appropriately. The HW solution to this problem comes in the form of advanced "HW acceleration" engines, which may be viewed as a generalization, for general purpose CPU's, of the traditional specific functionality of ASIC or NP designs.

Much, much research and development is being devoted to this issue at the current time by HW vendors. But even with the advances made so far, the general problem remains the same: how can equipment providers maximize the overall CPU utilization and therefore exploit the apparent parallelization potential of a multi-core device?

There are two problems here:
1) burst network workload due to a variety of both technical and environmental issues, and 2) the "packet affinity" issue, i.e. the ever increasing problem of client affinity and/or service affinity that is important for many (but not all) applications. Current hardware acceleration engine support does a fairly good job of solving the burst issue, being mainly focused on distribution of incoming packets to processing cores in an even manner. But most of these techniques involve a variation of a packet queuing approach wherein packets are distributed based on core queue size.

But this technique does not address
a) even distribution of processing load from multiple services across the cores, and b) the ever increasing problem of "affinity", i.e. correlation of packet streams from individual sources (clients) or by service type (usually involving protocols) in order to make some sense of the real logical networking streams that these systems are designed to address. Data path applications involving Deep Packet Inspection (DPI), firewall, intrusion detection and prevention (security) depend on client or source and destination correlation "client affinity". And routing, connectivity, security, and other protocols can benefit from both client based and service based affinity, where individual devices will be required to support multiple traditional routing protocols and other services simultaneously. So affinity also dramatically affects the even distribution of processing load across cores.

Given the current state of affairs, the solution for even distribution of processing load, often called "load balancing", falls into the realm of software. And this is the kind of software that many if not most equipment providers bring to differentiate their offering in the market. But where there is a common problem, there can be a common solution. In other words, what this all means is that new mechanisms for load balancing are necessary. But this is not just a simple HW/SW problem because it involves not just packet flow, but in some cases, an understanding of the semantics of the content of the flow itself.  This trend then leads to trend 3...

Enea is moving towards answers to the above trends. Link to Enea Multicore Whitepaper 

Trend 3 will be published later on this week.

 

Top 3 Trends in IP Packet Processing Systems: GPUs in Data Path

 

by Michael Christofferson

I was recently talking with some associates about the obvious recent industry trend that general purpose multi-core processors (e.g. devices from FreeScale, Cavium, LSI, NetLogic, Intel, AMCC, etc) are supplanting more traditional approaches for IP data plane or data path management, meaning  ASICS or specialized Network Processor (NP) devices. I and my associates work for an RTOS/Embedded Systems company and so it all seemed so obvious to us (we love more programmability). But on deeper reflection, the reasons weren't so clear cut, at least in a logical or empirical way. So I started trying to collect some thoughts given the deep experience that Enea has had in this space. What I found was that the underlying reasons for this trend are instructive in that they point to several associated trends that ultimately involve the underlying software and software architecture. So let's investigate:

Trend 1 - General Purpose Multi-core processors in the Data Path

There is a strong and continuing trend in next generation IP based networks and systems design for adoption of new protocols and services to be pushed into low or intermediate level processing nodes of a system, i.e. data path. This is especially true for routers that support L2-L4 protocols, but the same principle applies to other applications as well like media gateways, switches, intrusion detection and prevention, deep packet inspection, etc. This means that for cost effectiveness, individual data path processing nodes will be required to support an ever increasing set of services and protocols whose requirements vary greatly in terms of hardware resources and quality of service levels. Traditionally, the focus in data path has been raw performance wherein highly optimized ASIC design provides the best possible solution. To a lesser extent, optimized NP devices have fulfilled the same role but with more programmability. But these solutions work best in an environment wherein the protocol or service functionality set is fairly small or simple and where the degree of isolation between services is high so that a high level of parallelism may be achieved. In such a scenario, it is fairly straightforward to "over-provision" the number of processing units required to meet fluctuating demand (burst behavior). However, these approaches are not practical in the next generation networking environment that require more diverse services as well as stronger requirements on "packet affinity" on both the client and service level (more on "affinity" below), and that can more flexibly adapt to new functional requirements. And further, we are now seeing that some traditional control plane functionality is also being driven down into the data path, again for more efficiency and performance. Add this all up and we find that traditional general purpose programmable embedded CPU designs (based on MIPS, PowerPC, Intel, etc architectures) are now becoming the solution of choice primarily because these have standard embedded software eco-system support like real time OS, compilers, and software tools to address the new demands on flexibility and thus programmability. As for performance, with recent technology advancements that are now promising dozens to hundreds of general purpose CPU cores in a multi-core device within a few years, all with "hardware acceleration" engines for packet processing, then the bandwidth issue is apparently addressed. But while all this sounds great - software developers can use standard and well understood OS and programming API solutions, HW developers can deploy more and more bandwidth cost effectively - this simply leads to new challenges. Next trend, please!!

 

Enea is moving towards answers to the above trends. Link to Enea Multicore Whitepaper 

Trend 2 will be published next week.