►
From YouTube: Slirp is Dead, Long Live Slirp! A New Approach to User-mode Networking - Stefano Brivio & Alona Paz
Description
Slirp is Dead, Long Live Slirp! A New Approach to User-mode Networking - Stefano Brivio & Alona Paz, Red Hat
Originally written for completely different purposes, Slirp has conveniently provided user-mode networking to qemu for 18 years. Now consumable as libslirp, it can be set up quickly, almost independently of environment and topology, and is available without special security privileges. But it was never intended for this life.
Enter passt. passt(1) is an implementation of user-mode networking for qemu, focusing on security (no dynamic memory allocation, purpose-written codebase, strict seccomp policy), performance (packet and syscall batching, pre-cooked buffers, minimalistic TCP adaptation), network transparency: contrary to libslirp, NAT is not needed, as the guest inherits addressing and routing from the host via DHCP, NDP, DHCPv6.
The aim is to bring production readiness to user-mode networking with a simpler implementation, written with the specific goal in mind.
This talk presents motivation and history behind the passt project (with a focus on its proposed usage in KubeVirt), status, challenges, future perspectives (such as vhost-user support for further performance improvement, aiming at challenging throughput figures from multi-queue tap devices).
B
So
hi
I'm
Arona,
Turner
native
virtualization
team
at
redhead
I'm,
a
maintainer
of
the
cube
world
and
in
the
past
of
over
the
engine,
back-end
ndui
Stefano
is
the
one
that
develops
bestie
and
they
know
the
all
the
details
about
how
it
works.
But
I
know
why
wind
cube
root,
really
needed
it
and
how
we
incubers
are
using
it.
A
And
I'm
Stefano
brivio
I'm
a
kernel
developer
when
I
get
the
chance
I'm
with
virtual
networking,
I
hope,
I,
say
the
name
of
the
team
right
at
radar
and
when
I
hear
about
pods
I,
don't
think
of
kubernetes
I
get
hungry
so
yeah
that
that's
why
we
really
need
a
loan
up
for
this,
because
otherwise
I
wouldn't
know
the
context
the
stock
is
not
about.
So,
let's
you
might
have
high
expectations.
So,
let's
reset
them!
It's
it's
just
a
tiny
bit
about
slip.
It's
not
about
rust,
I'm,
sorry!
B
So
it
is
a
bit
just
a
bit
about
what
is
kubernetes,
what
is
Gilbert
and
we'll
explain
about
the
existing
kubernet
networking
approaches
and
why
those
approaches
were
not
enough
and
we
needed
to
think
about
a
new
approach
bestie
and
finally,
we
will
explain
about
what
is
best
in
the
how
it
works.
So
what
is
kubernetes
kubernetes?
It
is
an
open
source
system
and
it
is
used
to
automate
the
deployment,
scaling
and
management
of
the
containerized
applications.
B
B
Is
an
add-on
that
extends
kubernetes?
It
adds
resources
for
virtual
machines,
so
with
cubert
it
is
possible
to
run
virtual
machines
alongside
pods
in
a
kubernetes
cluster.
The
virtual
machines
can
be
managed
in
the
same
manner
that
regular
part
that
regular
pods
are
managed
in
the
kubernetes
cluster,
with
the
same
tools
like
Cube
CTL,
for
example,
since
the
basic
unit
of
kubernetes
is
a
pod
and
the
virtual
machine,
we
are
running
it
inside
the
Pod.
B
Service
meshes
so
service
meshes
are
one
of
the
main
reasons
that
we
needed
pestis.
So
I
will
explain
a
bit
about
them
and
there
are
different
implementation
of
service
meshes.
One
of
the
famous
ones
is
the
open
source
project
istio,
so
service
mesh
is
basically
a
way
to
control
how
different
parts
in
the
system
share
data
and
between
one
and
the
other.
The
architecture
of
service
meshes
in
a
kubernetes
cluster
is
that
inside
each
one
of
the
pods
that
is
managed
by
the
service
mesh,
a
sidecar
proxy
is
added.
B
So
since
this
sitecore
proxy
is
just
a
container
that
is
running
inside
the
Pod,
and
it
assumes
that
the
other
applications
that
it
manages
their
data
are
also
just
yet
another
containers
in
the
Pod.
So
the
sidecar
proxim
assume
that
it
shares
the
same
network
namespace
with
the
other
applications
in
the
Pod.
B
It
may
assume
that
it
can
see
the
sockets
and
the
processes
of
the
applications
that
it
can
do
soccer
through
Direction
Port
mapping,
IP
mapping
that
it
can
see
the
addresses
and
the
routes
of
the
Pod,
and
also
it
may
assume
that
the
data
that
it
controls
comes
from
the
user
space
of
the
Pod,
so
in
case
of
applications
that
are
running
in
regular
containers.
It
is
easy
to
meet
those
assumptions,
but
in
our
case,
when
we
are
running
our
applications
inside
the
VM
guest,
it
is
much
harder
to
meet
those
requirements.
B
B
So
cubert
today
has
several
ways
of
how
to
bind
how
to
connect
the
VM
Network
to
the
Pod
Network.
The
two
main
options
that
we
have
are
called
Bridge,
binding
and
masquerade
binding
in
the
case
of
the
bridge
binding.
What
basically
happens
is
that
all
the
networking
information
is
removed
from
the
Pod
interface
and
applied
on
the
VM
interface.
So
we
can
see
in
the
diagram
that
the
interface
of
the
Pod,
the
one
in
the
green
people-
we
see
that
it
doesn't
have
IP
address,
and
it's
just
not
just
the
IP
address.
B
B
The
guest
and
the
the
Pod
interface
are
directly
connected
with
layer,
2
connectivity.
We
have
a
bridge
that
one
part
of
it
is
connected
to
the
VM
interface
and
the
other
one
is
connected
to
the
Pod
interface
in
this
kind
of
binding.
We
cannot
run
sidecars.
We
cannot
run
extra
containers
inside
the
Pod
that
is
running
the
VM,
because
any
data
that
enters
the
Pod
enters
the
8th
zero
of
the
Pod.
It
directly
goes
to
the
VM
guest
because
there
is
a
direct
layer
to
connection.
B
The
other
binding
that
we
have
is
called
masquerade
binding
in
muscular
binding.
The
VM
is
basically
sitting
behind
the
nut.
Nf
tables
rules
inside
the
Pod
are
used
to
masquerade
and
the
denotes
the
traffic
from
and
to
the
VM.
We
can
see
that
the
VM
guest
has
a
internal
AP,
10
0
1
2.
It
is
a
internal
AP.
The
VM
is
not
directly
connected
to
the
Pod
interface.
It
is
just
connected
to
a
bridge
inside
the
the
Pod,
so
any
traffic
that
goes
from
the
VM
it
lands
on
the
bridge.
B
The
bridge
is
the
default
gateway
of
the
VM,
and
then
it
is
masqueraded
because
we
have
NF
table
rules
and
the
other
way
around.
We
have
dinner
tools
in
this
binding.
We
can
have
sidecars
and
there
is
no
direct
connection,
so
we
can
have
side
cars,
but
there
are
other
assumptions
that
the
service
mesh
has
that
are
not
met
here,
for
example,
the
data
that
arrives
from
the
guest
applications.
It
doesn't
arrive
from
the
user
space
of
the
Pod,
it
doesn't
land
there
because
it
goes
directly
to
the
kernel
space.
B
B
So,
besides
the
fact
that,
as
I
presented
in
the
previous
slides
that
we
don't
have
a
seamless
integration
with
the
service
meshes
with
these
two
bindings,
we
have
some
more
disadvantages
with
them.
We
had
to
implement
them
from
scratch
by
ourselves.
We
had
to
implement
the
DHCP
server.
If
we
want
multicast,
we
have
to
implement
it
too.
B
Another
disadvantage
is
that
our
pod,
the
Pod
that
is
running
the
VM-
it
is
unprivileged
POD,
it
doesn't
have
net
admin,
it
doesn't
have
Network,
as
we
saw
in
the
diagrams.
We
are
adding
tab
device.
We
are
adding
bridge
in
the
Masquerade
binding.
We
are
editing
the
NS
tables.
Those
requires
at
least
net
admin.
We
don't
have
it
so
we
had
to
use
some
tricks
to
make
it
work.
It
was
not
a
straightforward
at
all.
B
So
because
of
this
disadvantages,
we
started
thinking
together
with
the
Stefano's
team
about
a
new
binding
and
this
binding
is
called
the
past,
and
so
in
a
past
binding,
it
is
implementing
a
translation
layer
between
layer,
2
and
layer
4..
We
can
see
in
the
diagram
that
we
don't
add
any
extra
network
devices
to
the
Pod.
We
don't
have
a
bridge,
we
don't
have
tap,
we
don't
have
any
of
them.
We
just
have
a
process,
a
regular
process,
the
past
process.
B
It
is
universal
tool,
it
will
be
in
the
future
part
of
the
qmo
and
delivered
and
also
it
doesn't
require
extra
network
security
capabilities
cabinet
admin
cup
Network
are
not
required.
A
pesty
is
already
supported
by
cubert,
but
in
the
future
we
are
thinking
of
even
replacing
our
existing
masquerade
and
Bridge
binding
with
pesty.
A
So,
let's
have
another
look
or
a
deeper
look
at
that
orange
box.
That
was
in
the
in
the
previous
diagram.
That's
that's
passed,
so
it
essentially
implements
a
translation
between
layer,
two
frames.
So
what
you
have
on
the
left
is
a
Unix
domain
socket
coming
from
kirimo
within
frames
and
magically
on
the
right.
You
have
layer,
4,
sockets,
so
TCP
UDP
icmp,
just
equal,
that's
what
the
kernel
allows
so
and-
and
you
see
that
this
needs
internal
knowledge,
of
course,
of
TCP
UDP
like
when
these
things
is
hidden
frames.
A
A
Now
you
might
have
thought
of
sleep
when
you
saw
that.
Maybe
so
it's
also,
it
does
essentially
the
same
thing:
it
Maps
qmo,
akumu
interface,
not
a
Unix
domain
socket,
but
a
cumin
interface,
two
hot
sockets,
so
it
implements
user
mode.
Networking
it's
very
simple:
it
doesn't
need
any
security
privileges,
but
it
would.
It
was
really
written
for
a
different
purpose.
So
there
were
a
few
problems
with
with
those
with
those
topics
in
particular,
so
there
is
no
focus
on
performance
in
the
Europe.
It
forces
not.
A
A
So
now
that
we
talked
about
pods,
let's
talk
about
the
arguments
to
receive
message
so
on
the
left:
okay,
here
I'm
presenting
the
data
path,
that's
a
basic
data
path
that
passed
implements
so
on
the
left.
Just
imagine
that
you
have
qimo,
you
have
it
in
the
other
room
and
it
connects
surpassed
with
Unix
domain
socket.
A
Here
you
have
just
one
big
buffer,
so
no
per
connection
buffer.
So
that's
an
audible
difference
with
slip
and
it
allows
us
to
have
no
dynamic
memory
allocation,
so
we
are
abusing
the
kernel
buffers
the
host
kernel,
buffers,
of
course
to
buffer
things
for
us.
So
when
we
get
frames,
we
just
split
them
spread
them
there,
and
it
also
means
that.
Well,
we
need
to
actually
sorry.
This
is
a
bit
the
other
way
around.
A
A
So
we
we
cannot
kill
those
buffers,
so
we
cannot
really
remove
them
from
the
queues
until
they
are
acknowledged
from
the
from
from
kirimo
from
the
guests.
So
we
need
to
pick
it
down
first
and
then
Flash
the
buffers
once
we
we
know
that
they've
been
received
this
through
participate.
This
is
not
the
case
for
UDP.
Of
course,
this
is
what
I
was
talking
about
earlier
frames.
You
have
a
big
buffer
and
again
not
per
connection
buffer,
so
no
need
for
a
dynamic
memory.
A
Allocation
and
past
takes
those
ethernet
frames,
checks
which
socket
does
it
need
to
go
to
and
express
them,
and
we
have
a
similar
mechanism
to
avoid
implementing
a
further
congestion
control,
which
is
also
which
is
actually
implemented
in
clear.
So
we
don't
do
it.
We
just
asked
the
host
kernel
when
we
can
acknowledge
segments.
A
A
What
what
path
provides
is
sandboxing,
so
all
the
users,
all
the
namespaces,
that
we
don't
really
need
are
unshared.
So
the
past
process
doesn't
see
anything
after
it
starts.
It
doesn't
require
any
capabilities
because
it
doesn't
create
network
interfaces.
That's
the
same
as
lip.
It
doesn't
run
this
route
for
real.
A
A
So
it
should
have
some
advantages
to
to
write
it
in
Rust.
We
would
ensure
that
there
was
no
stack
based
overflows,
for
example,
on
the
other
hand,
it
it
it
is
probably
possible,
but
it's
quite
hard
to
completely
avoid
dynamic
memory
allocation
unless
we
use
the
last
chord
Library
instead
of
the
standard
one.
A
A
Let's
have
a
look
at
performance
topics,
so
you
might
think
well,
user
space
user
mode
is
working.
Okay,
it's
a
toy!
However,
it's
actually
not
that
bad,
it's
kind
of
competes,
so
those
are
tests
we
made
against
the
existing
bindings
in
in
Cubit.
So
this
is
just
not
filter
that
you
have
on
the
those
left.
Those
bars
on
the
left
and
past
is
actually
faster.
If
you
stick
to
once
a
single
tab
queue.
A
A
A
A
We
don't
have
any
congestion
control
additionally,
and
we
are
now
trying
to
work
on
the
difference
between
those
two
bars
so
the
to
solve
this
Gap
that
we
have
with
multi-tap
multi-q
tab
by
one
idea
that
looks
quite
promising
is
to
add
a
v
host
user
backhand.
So
we
would
have
one
copy
instead
of
two.
A
What
do
you
get
this?
Okay,
so
first
off
it's
Linux
only
for
the
moment,
because
we
really
interact
with
the
kernel.
We
also
kernel
a
lot
of
things
like
what
are
your,
what
is
your
current
sanding
window
and
how
many
segments
have
been
acknowledged
and
how
big
is
the
buffer,
so
this
is
now
probably
doable
with
most
flavors
of
PSE,
but
we
didn't
do
it
yet
Federal
packages
available.
A
That
will
be
true
actually
in
two
days,
so
they
are
in
the
repositories,
but
it's
still
in
the
testing
repositories
for
Fedora
35
and
on
for
other
distros.
We
have
unofficial
packages,
the
cube,
vertech
preview
that
Alona
mentioned
earlier.
We
have
a
PLC
for
cutter
containers,
the
Q
integration
yeah.
As
far
as
I
know,
that
series
is
not
applied
yet
but,
along
with
the
wrote,
a
proper
patch
set
implementing
native
F
Unix
socket
until
then
it
we
with
the
wrapper
and
I'm
working
right
now
on
a
leap
year
patch.
A
Those
are
links
to
list.
So
the
the
email,
the
the
patch
workflow,
is
email
based
one.
There
is
a
bug
tracker.
There
is
a
chat
and
I
wanted
to
quickly
mention
a
incarnation
of
past,
which
is
called
pasta,
which
is
the
same
trick
actually
implemented
by
the
same
binary.
It's
just
a
different
command
that
will
do
the
same
story
for
for
namespaces,
so
it's
an
equivalent
to
video
for
nothing
else.
I
already
proposed
it
to
podman
developers,
they
say
the
great,
but
where
are
the
packages
so
yeah?
A
A
I,
don't
know
because,
oh
sorry,
can
you
replace
leer?
Are
you
going
to
replace
lip?
That's
that
was
the
question.
I
think
it
can
replace
lip
right
now,
I'm,
not
thinking
of
of
proposing
it
as
an
alternative
for
Nat
user,
because
well
it
might
be
used
like
that,
but
yeah
it
should
be.
The
case.
I
mean
it
depends
a
bit.
I
didn't
really
ask
the
kirimu
community.
You
know
until
now.
So
I
think.
So
you
will
tell
me
you
you
guys,
will
tell
me.
A
Do
you
have
to
pull
under
on
the
tcpx
I?
Actually
don't
but
I
have
some
timeouts,
it's
it's
kind
of
opportunistic
polling,
so
usually
not,
but
there
are
some
our
the
whole
time,
rft
events
to
which
we
put
in
our
Apple
descriptor
and
yeah.
If
an
act
doesn't
come
for
too
long.
Yes,
we
actually
have
to
ask
the
colonel
again
hey
what
happened
to
this
yeah.
A
A
The
side
guard
going
to
the
Pod,
so
the
traffic
between
sidecar
and
pod
go
through
the
Cardinal
Edge
time.
Yes
yeah
so
essentially
well,
it
depends
I
mean
with
the
viosk
user
backhand.
We
would
probably
I.
Guess
you
mean
by
between
sidecar
and
the
m,
so
okay,
the
VM
year
becomes
part
of
the
Pod.
So
right
now,
yes,
and
it
goes
an
awful
amount
of
times
back
and
forth
because
it
it's
actually
going
to
the
Unix
domain,
socket
back
to
user
space.
A
Past
gets
it
and
there
are
two
copies.
Those
are
cheap,
but
still
there
are
two
copies,
so
there
is
a
read
and
the
send
on
the
socket,
so
with
Vios
user.
We
would
reduce
it
a
lot
because
we
bypass
qimo
essentially
so
Kimo
would
just
be
in
charge
of
setting
up
the
data
path
and
then
the
well.
We
would
get
it
from
the
guest
memory
and
then
we
would
just
have
one
copy
that
is
from
that
buffer
to
sanding
on
the
socket.