The document discusses the goals and requirements of an abstraction layer (AL) for networking applications. The AL aims to decouple innovation between network application vendors and hardware vendors to allow both sides to innovate independently. It seeks to define a common interface that supports different hardware architectures, provides offloads, and enables applications to efficiently move packets while being hypervisor agnostic and portable across systems. The requirements include functional characteristics like packet processing as well as non-functional aspects like security, performance, extensibility, and manageability.

1. Userspace 2015 | Dublin
DPDK Architecture Musings

2. Architecture Musing
AL
(Network,
Crypto,
Disk,
…)
Containers/VM’s
Intel
Freescale
Cavium
FPGA
etc
…
Cloud/SDN
Embedded/IoT
TradiIonal
Wrapper
Facade

3. AL Goals
• Decouple
the
innovaIon
boundary
• Allow
network
applicaIon
vendors
to
innovate
above
the
line
without
having
to
build
custom
soluIons
for
each
HW
vendors
processor,
SoC
or
NIC.
• Allow
processor,
SoC,
NIC
and
Crypto
vendors
to
innovate
below
the
line
without
having
to
do
something
special
for
each
network
applicaIon
vendors
implementaIons.
• Increase
Velocity,
Reduce
Effort
and
Improve
Quality
• Enable
network
applicaIon
vendors
the
ability
to
rapidly
prototype
in
a
given
environment
without
significant
investments
in
Ime
and
engineering
effort.
• Define
an
abstracIon
that
allows
vendors
on
each
side
of
the
boundary
to
focus
on
hardening
of
the
pieces
they
own
• Network
applicaIon
performance
portability

4. AL Requirements
• Common
&
Open
Interface,
supporIng:
• Different
Vendor
IO
architectures
• Leverage
Hardware
Offload
if
available
• Cryptography
and
security
protocol
assist
• ClassificaIon
and
packet
steering
• Time
measurement
and
event
management
• PlaXorm
Diversity
• Wide
range
of
performance
and
cost
points
• Embedded
dedicated
devices
and
Data
Center
server
environments
• Efficient
model
for
packet
movement
• North/South
and
East/West
• Hypervisor
AgnosIc

5. AL Requirements
• Roles
and
responsibiliIes
clearly
defined
• Clearly
defined
model/semanIcs
• FuncIonal
CharacterisIcs
(this
tends
to
be
covered
well)
• Non-­‐funcIonal
CharacterisIcs
(not
so
obvious
but
kill
you)
• Security
for
deployment
(least
privilege)
• Performance
(this
is
what
most
people
concentrate
on)
• Extensibility
(how
can
we
extend
but
not
change
the
interface)
• Management
and
instrumentaIon
• ConfiguraIon,
deployment
and
tuning

6. Finally (well almost)
• Portability
across
systems
• Source
Code
• Performance
• Good
DocumentaIon
• Test
Framework

7. Q&A