OpenDataPlane Project

OpenDataPlaneTaras KondratiukCisco Systems

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential

▪ The talk is based on my previous work in GlobalLogic, Texas Instruments and Linaro

▪ It is not related to my work in Cisco

Disclaimer


Overview▪ Why OpenDataPlane is needed?▪ Basic design principles▪ Typical packet processing flow


▪ HW is not flexible▫ HW can handle a predefined set of protocols▫ Exception and control traffic should be handled on CPU▫ New version respin takes a lot of time/money

▪ Allows to quickly implement and experiment with a new network protocols

▪ More suitable for virtualization (NFV)

Software data plane - why?


▪ Each networking SoC vendor has their own SDK for data plane applications

▪ All were designed and highly optimized for the specific vendor’s silicon

▪ A lot of SDKs are proprietary▪ They are not compatible▪ Applications have to be ported to each of them

The problem


Vendor-optimized networking SDKsVendor RunTime Environment Hardware designed for

Broadcom HyperExec, NetOS XLR/XLS/XLP

Cavium Simple Executive Octeon

Freescale LightWeight Executive (LWE), USDPAA

QorIQ/DPAA

Intel DPDK X86+Intel NIC

Texas Instruments Multicore SDK (McSDK) TI Keystone

Tilera Zero-Overhead Linux (ZOL), Bare Metal Environment(BME), Netlib

Tile64/TilePro/TileGX


“All problems in computer science can be solved by another level of indirection” (David Wheeler) :)

The solution – OpenDataPlane


▪ Open source, open contribution framework for portable high performance data plane applications

▪ Common APIs provide application portability

▪ Optimized implementations of these APIs provide accelerated performance on each platform

▪ Wide architecture support: ARM, MIPS, PowerPC, x86, Tilera, Kalray

OpenDataPlane – what is it?


Shared design


OpenDataPlane – two perspectives

ODP app A ODP app B ODP app C

ODP DPDKimplementation

ODP Keystone2implementation

ODP SoC X implementation

X86 + Intel NIC

TI Keystone2 SoC X

TI McSDKDPDK

ODP API

SoC X SDK

Applications run on any platform

Silicon vendor compete for any socket

ODP SoC Y implementation

SoC Y


▪ ODP APIs▫ Common definitions, build tools, and validation tests▫ Open contribution, LNG is maintainer and upstream

▪ ODP Implementations▫ Developed and maintained by sponsoring owner▫ Typically SoC vendor▫ Can be open or closed source at implementor’s option

ODP components


▪ API should reflect application use models

▪ API should map efficiently to HW accelerators

▪ Allow gradual migration from vendor’s SDK to ODP

▪ Event based programming model

▪ Scalability on multicore SoCs

▪ Execution environment agnostic: Linux process, bare metal, virtualized, etc.

OpenDataPlane – design principles


▪ Abstract types▫ All ODP types are opaque handles:

odp_packet_t, odp_pool_t, odp_queue_t, etc.▪ Functional abstractions

▫ ODP APIs define functions, not data structures

ODP abstractions


Typical ODP packet flow

Ingress pre-processing

Scheduling,main processing

Egress post-processingPorts Ports


Ingress – simple case

Port Packet IO

Pool

Packet storage

free packet

dataQueue

Port abstraction

filled packetInput to a next stage


Ingress – classification

Port 1 Packet IO

Pool

Queue

Classifier

Port N Packet IO

Packet Matching Rule

Class of Service A

Pool

QueueClass of Service B

Match specific packet header field

CoS’s can be cascaded

Input queues


▪ ODP is highly influenced by Open Event Machine▫ “Run to completion” model▫ Event based: packet, timeout, buffer, etc are all events▫ Every interface is a queue

▪ Event scheduler is a central part▫ Automatic load balancing▫ Handles prioritization▫ Help with serialization and order

Main processing – scheduler


Main processing – scheduler

Queue

Scheduler

Thread

Queue

Queue Thread

Thread

EngineThread

Queue

Queue

events can be enqueued to be scheduled again

Output queues

Scheduler selects the next event for a thread

Threads invoke engines via ODP API (for example Crypto)

Queues hold events to be processed


▪ Not synchronized▫ Multiple outstanding events without restrictions

▪ Atomic▫ Only one outstanding event at a time

▪ Ordered▫ Multiple out-standing events▫ Event order is restored when events are sent to

another queue

Scheduler queue types


Egress

Queue

Traffic Manager

Packet IO

Queue

Queue

Loopback

Back to Ingress

Port 1

QoS and Shaping Rules

Packet IO Port 2

Packet IO Port N

Egress API definition is still in progress

Cisco Confidential© 2015 Cisco and/or its affiliates. All rights reserved.

Questions?

Thank you


Links▪ www.opendataplane.org▪ https://git.linaro.org/lng/odp.git▪ http://www.slideshare.net/linaroorg/hkg15110-odp-project-update▪ http://www.slideshare.net/GMA87/learn-more-about-the-tremendous-value-

open-data-plane-brings-to-nfv▪ http://www.slideshare.net/linaroorg/nfv-linaro-conference-sep2014kolias?

qid=fdb1effe-4c0e-4c66-be34-779e963f8003&v=default&b=&from_search=10

http://www.opendataplane.org

http://www.opendataplane.org

https://git.linaro.org/lng/odp.git

https://git.linaro.org/lng/odp.git

http://www.slideshare.net/linaroorg/hkg15110-odp-project-update

http://www.slideshare.net/linaroorg/hkg15110-odp-project-update

http://www.slideshare.net/GMA87/learn-more-about-the-tremendous-value-open-data-plane-brings-to-nfv



http://www.slideshare.net/linaroorg/nfv-linaro-conference-sep2014kolias?qid=fdb1effe-4c0e-4c66-be34-779e963f8003&v=default&b=&from_search=10



Engineering

OpenDataPlane Project