►
From YouTube: Move fast and don't break things: High-performance networking in Rust — Joshua Liebow-Feeser
Description
What makes Rust different is not that you can write high-performance, bare-metal code. What makes Rust different is that when you write that code, it is clean and easy to use, and you are confident in its correctness.
In this talk, we discuss a new, high-performance networking stack being written in pure Rust. We discuss how Rust has allowed us to squeeze every last drop of performance out of the stack without sacrificing usability, productivity, or the confidence that our code is bug-free. We focus specifically on packet parsing and serialization, which we accomplish with zero copying, zero heap allocation, and very little unsafe code.
---
Josh is a security engineer at Google working on Fuchsia, where he gets to program in Rust all day long. He also programs in Rust as a hobby, which makes him very well-rounded.
A
Thank
you
for
that
all
right
sake
of
not
running
over
time.
A
little
bit
about
me.
First
I
work
at
security
at
Google
I
get
to
work
on
open
source
rust,
which
is
really
cool.
If
that
sounds
like
something
you
would
like
to
do,
rust
or
security
or
both
come
talk
to
me
and
I
just
started
the
secure
code
working
group
for
rust,
if
you're
interested
in
that
also
come
check
us
out
the
thing
we're
going
to
be
talking
about.
So
the
thing
is
a
experimental
networking
stack
handles
the
link
layer
through
the
transport
layers.
A
Like
you
know,
you
throw
net
through
TCP
and
UDP.
It
is
written
in
pure
rust.
Obviously,
design
goals
are
for
low
resource
environment
so
like
low
CPU
utilization,
low
binary
footprint
and
finally,
it
is
structured
as
a
platform,
agnostic
core
and
then
some
platform
specific
bindings.
So
if
you
are
interested
in
using
this
thing
for
your
kernel
or
your
project
or
whatever,
please
let
me
know
it,
you
know
it's
it's
obviously
very
early
api's
are
changing,
but
if
it's
just
you
know
sort
of
experimental,
it
could
be
cool.
A
A
quick
note
on
the
subtitle
that
was
advertised
high
performance.
This
networking
stack
can
currently
respond
to
pings.
That
is
all
it
can
do.
Yes,
thank
you,
yeah
and
so
yeah.
So
when
I
say
high
performance,
I'm,
not
referring
to
like
actual
benchmarks,
I'm,
referring
more
to
design
to
the
fact
that
we
can
prove
statically
that
a
bunch
of
things
are
happening
at
compile
time
rather
than
runtime.
I
I
suspect
that
this
will
lead
to
actual
good
performance
later,
but
I
don't
know
so
we'll
find
out.
So
brief
outline
for
the
talk.
A
First,
we're
going
to
talk
about
design
goals
for
the
stack
and
the
stuff
we're
gonna
be
talking
about,
give
a
little
bit
of
background
on
packets
and
how
they're
laid
out
just
to
get
everyone
on
the
same
page.
First
we're
going
to
talk
about
parsing
packets,
then
we're
gonna
talk
about
serializing
packets,
then
we're
going
to
talk
about
forwarding,
which
is
basically
parsing
and
then
serializing,
packets,
right,
yeah,
it's
very
fancy
and
then
finally,
we're
going
to
talk
about
some
nitty-gritty
details
of
how
we
do
zero
copy
in
a
safe
way.
A
So
the
goal
for
that
for
this
design,
so,
first
of
all
zero
copying
when
I
say
zero,
copying,
I,
don't
literally
mean
no
memory
reads
or
writes.
Obviously,
but
if
we
have
a
big
buffer
and
there
is
a
packet
living
in
the
buffer-
and
we
want
to-
we
want
to
operate
on
it.
So
we
want
to
parse
it
or
modify
it
or
serialize
a
new
packet
into
the
buffer.
We're
not
gonna
like
pull
it
out
into
some
scratch
space
and
operate
on
it
and
then
move
it
back.
We're
just
gonna.
A
Do
everything
directly
in
place,
as
I
said.
We
expect
this
to
make
it
high-performance
well
find
out.
The
second
thing
is
euro
heap
allocation,
so
everything
is
on
the
stack
and
then
finally
a
zero
unsafe
right,
so
no
use
of
the
unsafe
keyword.
This
may
sound
like
really
cool
and
too
good
to
be
true,
that's
because
it
is
there's
actually
a
little
bit
of
unsafe,
but
in
standard
rust
fashion
that
unsafe
is
sort
of
self-contained
in
little.
You
know
nice
little
small
packages
and
it
can
be
nicely
composed.
Another
thing
I
want
to
clarify
here.
A
This
is
not
a
look
at
the
cool
things
you
can
do
in
Russ
talk.
This
is
a
look
at
the
cool
things
you
could
do
safely
in
Russ.
Talk.
Everything
that
we're
gonna
describe
here
today
can
be
done
and
is
done
in
C
and
C++.
The
only
difference
there
is
it's
very
unsafe
and
you
the
programmer,
have
to
verify
a
lot
of
properties
yourself.
So
the
distinction
here
is
not
like.
We
can
do
this
thing,
but
rather
we
can
do
this
thing
differently.
A
A
So,
all
right,
so
a
little
bit
of
background
on
how
network
packets
are
laid
out.
So
packets
are
just
a
big
sequence
of
bytes.
The
all
these
diagrams
that
you're
gonna
see
today
are
beginning
byte
on
the
left
and
byte
on
the
right.
Packets
are
recursive,
so
the
analogy
that
we're
gonna
be
using
throughout
the
entire
talk.
I
hope
you,
like
onions,
we're
gonna,
be
talking
a
lot
about
onions.
So,
basically,
you've
got
a
packet
which
contains
a
packet
which
contains
another
packet
which
contains
another
packet
and
so
on
and
so
forth.
A
The
packet
that
we're
gonna
be
talking
about
are
just
a
header
and
a
body
I'm.
Sorry
for
those
of
you
who
really
like
packet
formats,
no
packets
with
footers,
so
there's
a
there's,
a
format
header
there's
a
hair
at
the
beginning,
whose
format
is
fixed
as
in.
If
you
go
and
read
the
Ethernet
spec,
for
example,
you
will
see
there
is
this
field,
and
then
this
field
and
blah
blah
blah.
So
the
header
has
a
well-known
format
that
we
can
parse
and
then
the
body
is
completely
unstructured
and
variable
length.
We
have
no
idea.
A
What's
in
there,
it's
completely
opaque
now,
once
we
know
what
is
in
there,
that
might
be
a
different
format
which
we
can
go
parse.
So,
for
example,
we
might
discover
that
oh
look,
there's
an
IP
packet
in
there
and
then
we
can
go
pull
out.
The
IP
spec
and
we
can
read
it
and
say:
oh,
this
is
how
you
parse
an
IP
packet,
but
from
the
perspective
of
Ethernet,
it's
completely
opaque.
A
So
let's
say
that
we
have
this
IP
packet
here
we
might
say
well
we're
gonna
parse
this
again
again
an
IP
packet
just
in
the
same
way
there's
a
format
header
the
beginning.
We
know
we
know
what
that
format
is
and
then
there's
an
unstructured
body.
Maybe
this
contains
a
UDP
packet
and
you
know
so
on
and
so
forth.
We
can.
We
can
keep
going
like
this.
An
important
thing
to
keep
in
mind
here
is
that
when
we're
parsing,
we
don't
actually
know
ahead
of
time
what
all
of
these
types
are
going
to
be.
A
So
we
might
get
an
Ethernet
packet
and
we
don't
know
what's
inside
of
it,
it
might
be
an
ARP
packet,
it
might
be
an
IP
packet.
We
actually
have
to
look
at
the
header.
The
header
tells
us
what's
inside,
so
we
actually
don't
know
until
runtime.
What
the
next
thing
that
we're
gonna
parse
is
so
this
can.
This
is,
unfortunately,
it
has
to
be
less
static
than
you
might
like.
A
We're
gonna
parse
the
Ethernet
packet,
gonna
parse,
the
IP
packet
inside
of
you
from
that
packet,
then
we're
gonna
decide
to
forward
the
packet,
so
we're
actually
just
gonna
resend
it
to
somebody
else
and
first
we're
going
to
update
the
header.
We
have
to
do
some
updates
when
we
forward
packets
and
then
we're
gonna
serialize
it
inside
of
a
new
Ethernet
packet,
and
all
of
that
is
going
to
happen
in
place
on
the
stack,
no
copying.
A
So
that's
the
goal
that
we're
building
up
to,
but
first
we
have
to
get
through
some
other
things,
namely
parsing.
So
the
goal
of
this
section
is
a
lot
simpler.
We
were
going
to
allocate
a
buffer
on
the
stack
and
we're
going
to
receive
an
Ethernet
frame
into
that
buffer,
we're
gonna
parse
the
packet
we're
going
to
parse
the
packet,
we're
gonna
parse,
the
pack
anyway,
this
is
the
fit.
You
get
the
idea,
a
very
simple
example:
we
just
receive
it
and
parse
parts
parts
more,
sparse.
A
That's
the
whole
example
for
this
section,
so
all
right,
the
buffer,
trait
the
buffer
trait,
is
a
really
important
trait
in
the
net
stack.
It
is
sort
of
like
the
core
trait
for
parsing
and
serialization.
The
reason
that
it's
a
trait
and
rat
and
not
a
concrete
type,
is
that
we
have
a
bunch
of
implementations
of
it,
but
the
detail
there
aren't
important.
A
A
really
important
thing
to
keep
in
mind
with
buffers
is
that
they
are
referencing
and
by
that
I
mean
that
when
you
say
you
have
ownership
of
a
buffer
object,
that's
just
a
tiny
little
struct
thing
with
some
pointers
right,
maybe
it's
an
own
point.
Maybe
you
know
maybe
it's
owned.
Maybe
it's
a
reference
to
something,
but
the
point
is
that
thing
is
tiny.
The
buffer
bytes
themselves
live
somewhere
else.
A
So
we're
going
to
talk
about
like
moving
these
things
around
a
lot,
keep
in
mind
that
that's
a
very
cheap
operation,
because
this
is
basically
just
a
point.
So
these
things
are
basically
just
a
sequence
of
bytes.
Just
like
a
packet
would
be.
You
might
ask
the
question
reasonably.
Why
is
this
not
just
a
slice?
A
Well,
the
answer
is
that
we
need
to
keep
track
of
how
much
we've
parsed
so
far
or
how
much
we
have
serialized
so,
for
example,
or
sorry,
so
so
the
way
that
we
do
this
is
we
split
the
the
buffer
into
a
prefix
and
a
body.
The
prefix
is
basically
everything
that
I
have
not
parsed
or
serialized
so
far,
I'm,
sorry,
everything
that
I
have
parsed
or
not
serialized,
and
then
the
the
body
is
everything
else
so
I.
So
it's
essentially
just
a
pointer
into
the
buffer
right.
A
It's
you
know,
here's
the
whole
buffer
and
here's
where
I
am
so
far
right,
so
you
can
consume
bytes
from
the
body
and
they
get
added
to
the
prefix.
So
I
can
shift
this
way.
You
can
consume
bite
from
the
prefix
they
get
out
of
the
body
shift
that
way
and
the
invariant
that
we're
trying
to
maintain
here-
and
this
is
gonna-
be
really
important
through
the
through.
A
The
current
thing
in
the
body
is
everything
that
I
have
serialized
so
far
and
when
I
ask
please
serialize
your
header,
it
starts
where
we
left
off
and
goes
this
way
and
expands
the
body
to
include
the
now
larger
packet.
So
what
is
in
the
body
is
really
important
where
that
body
is
versus
the
prefix.
That's
going
to
be
the
sort
of
the
core
of
everything
here,
so,
let's
walk
through
an
example
the.
So
this
is
a
diagram
here
on
the
bottom.
A
We
have
the
actual
physical
structure
of
the
packet
or
at
sorry
of
the
buffer.
Excuse
me
so
it
starts
off
as
being
all
body
on
the
top.
We
have
the
logical
view.
So
logically,
the
contents
of
these
bytes
are
an
Ethernet
header
and
an
Ethernet
body,
but
we
don't
know
that
yet,
and
so,
when
we
parse
it,
it's
gonna
look
a
little
something
like
this.
So
what
we
have
here
is
the
result
of
parsing
is
an
Ethernet
packet
object.
Ethernet
packet
object
is
a
tiny
little
struct
that
just
has
some
references
into
the
buffer.
A
Okay
again,
this
is
a
zero
copy
theme
here.
The
Ethernet
packet
object
is
just
references,
so
it
has
one
reference
into
the
header
and
then
one
reference
into
the
body.
An
important
thing
to
keep
in
mind
here
is
that
the
header.
Well,
so
the
body
is
just
bytes.
We
don't
know
what
it
is.
So
that's
just
a
that's
just
byte
slice
right.
The
header,
on
the
other
hand,
is
actually
structured,
so
we'll
get
into
at
the
end
of
the
talk
how
we
actually
achieve
that
without
safe.
A
But
this
you
should
basically
think
of
this
as
a
struct
reference.
Okay,
so
we
have
a
struct.
It
represents
what
the
header
actually
looks
like
right.
We've
got
this
field
and
in
that
field,
and
so
on
and
so
forth-
and
this
is
just
a
reference
in
that
struct,
so
we
can
just
access
it
like
plain,
vanilla,
rest,
write,
struct,
dot,
field,
blah
blah
blah
blah
last
thing
to
note
is
because
these
are
references.
The
ethernet
packet
object
borrows
the
buffer.
A
So
if
we
want
to
actually
move
the
buffer
around
which
we
will
want
to
do,
we
have
to
drop
the
packet
first
and
so
a
pattern
that
you're
gonna,
see
over
and
over
again
is
first,
we
parse.
Then
we
operate
on
that
actual
object
and
then
before
we
do
anything
else,
we
drop
it
and
then
we
pick
up
where
we
left
off,
but
now
we've
forgotten
about
that
thing.
Right,
okay,
so,
as
we
said
before,
we've
got
this
and
then
we're
gonna
drop
it.
A
It
goes
away,
and
so
what
we're
left
with
is
that
the
body
of
the
buffer
now
corresponds
to
the
body
of
the
ethernet
packet.
So,
as
I
mentioned
before,
we
can
just
pick
up
where
we
left
off
and
parse
the
next
packet.
So
the
exact
same
thing
happens
this
time
with
the
IP
packet.
We
have
a
header,
it
references
into
the
buffer
and
it
is
a
structured
reference
to
the
actual.
A
You
know
it's
a
struct
that
we
can
access
the
fields
and
then
an
unstructured
reference
to
the
body
it
borrows,
or
it
borrows
the
but
the
buffer,
and
so
when
we're
done
with
it,
we
have
to
drop
it.
Let's
look
at
a
little
example
of
what
this
might
look
like
in
code.
This
is
obviously
a
little
pseudocode
ish,
because
they're,
you
know
more
like
I
would
want
to
do
more
things
if
I
receive
in
Ethernet
packet.
But
this
really
is
the
core
of
it.
A
You,
the
buffer,
has
a
parse
method,
and
you
literally
say
here
is
a
type
of
a
packet.
Please
parse
it
for
me
done,
and
so
you
get
a
packet
object
back
here
and
then
you,
you
know
you
might
operate
on
it
and
then
you
drop
it
and
then
you
pass
that
buffer.
Again,
as
I
said,
you
pass
the
buffer
by
value
you're,
actually
passing
ownership.
This
will
become
important
later,
so
you
pass
the
the
buffer
by
ownership
to
the
next
layer
of
the
stack.
A
The
body
is
left
as
it
was
before
so
the
next
layer,
the
stack
just
picks
up
right
where
we
left
off.
So
let's
actually
look
at
what
this
might
look
like
in
memory
on
the
stack,
so
we
get
a
sense
of
how
all
the
memory
is
laid
out.
So
let's
say
that
we
receive
a.
We
have
a
buffer
that
is
allocated
on
the
stack,
so
it
sits
in
a
stack
frame
there.
A
First,
we
pass
the
buffer
in
to
receive
Ethernet
packet,
so
this
little
black
arrow
here
just
means
that
you
know
the
actual
object
is
here,
but
the
actual
bytes
of
the
buffer
are
still
in
the
original
back
frame.
First,
we
parse
the
ethernet
packet,
just
like
we
mentioned
before
so
the
Ethernet
packet
struct
itself,
which
is
this
tiny
little
thing.
It
lives
in
this
top
stack
frame
here,
but
the
references
are
all
into
the
contents
which
live
in
the
original
stack
frame.
A
Right,
no
copying,
so
we
drop
it
and
then
we
send
the
but
the
buffer
again
into
the
receive
IP
packet
function.
This
time
and
again,
we
parse
this
time
and
IP
packet
again.
The
reference
is
that
it's
tiny
little
struct
libs
and
that's
a
creme
and
the
references
point
into
the
bottom
stack
frame.
So
that's
parsing,
it's
very
straightforward.
Let's
get
into
serialization,
so
the
goal
here
is
that
we
are
going
to
receive
a
request
to
send
an
IP
or
UDP
packet.
So
there
is
an
application
that
says
I.
A
You
know
it's
like
a
DNS,
client
or
something
it
says
here
are
the
contents
of
a
UDP
packet
that
I
would
like
you
to
send
out
onto
the
network.
First
we're
going
to
compute
some
header
information
for
the
UDP
packet.
Then
we're
going
to
compute
some
routing
information
for
IP.
Where
are
we
sending
this
thing?
And
then
some
information
about
what
the
IP
header
will
need
to
have
then
some
Ethernet
routing
and
the
header
information
and
then
finally,
after
we've
done
all
of
this,
only
then
do
we
actually
compute
the
length
and
allocate
the
buffer.
A
So
all
the
computation
before
we
haven't
actually
been
doing
anything,
we've
not
been
serializing,
we've
not
been
doing
any
kind
of
allocation
only
at
the
bottom.
Do
we
actually
say:
ok,
now
that
we
know
how
big
the
packet
needs
to
be.
Now
we
can
allocate
the
buffer
I
know
that
I
said
stack
allocation
at
the
beginning.
A
We're
gonna
keep
allocate
in
this
example,
just
to
keep
things
simple,
we'll
actually
stack
allocate
in
the
end
and
then,
finally,
once
we
have
a
buffer,
then
we
can
just
serialize
in
one
big
pass:
UDP
UDP,
bot
or
UDP
header,
IP,
header,
Ethernet
header,
and
then
we're
done
so
a
little
note
on
why
this
is
hard.
Some
of
you
in
the
audience
may
be
thinking.
Ok!
Well,
if
you
know
how
big
the
packet
is,
why
don't
you
just
like
allocated
ahead
of
time?
Why
do
you
have
to
do
all
of
this
sort
of
weird
stuff?
A
And
the
answer
is
that
you
need
to
send
the
request
to
the
next
layer
before
you
serialize.
So,
for
example,
if
I
have
a
UDP
body
and
I
want
to
say
well,
I
need
to
know
what
buffer
I'm
going
to
serialize
it
into
I
have
to
know,
obviously
how
big
all
of
the
headers
are
going
to
be
so
I
know
how
big
the
buffer
needs
to
be,
but
the
IP
layer
needs
to
know
where
it's
sending
the
thing
in
order
to
know
which
link
layer
protocol
is
being
used.
A
Am
I
sending
it
over
an
Ethernet
network
that
has
a
header
of
this
size?
Am
I
sending
it
over
a
Wi-Fi
network
that
has
a
larger
header
right,
so
you
need
to
actually
compute
all
the
routing
information
before
you
know
how
big
the
buffer
needs
to
be,
and
so
there's
this
chicken
and
egg
problem
where,
in
order
to
call
the
function,
that
says,
please
send
this
thing.
For
me,
it
cannot
be
serialized
already,
but
of
course
you
can't
get
control
flow
back,
because
the
thing
needs
to
be
sent
by
the
time
you
send.
A
You
call
the
function,
and
so
that's
why
this
is
difficult
and
we'll
see
how
we
solve
this
problem.
So
the
first
trait
that
we're
gonna
introduce
to
deal
with
parsing
is
the
packet
builder
trait
remember
before
that.
I
said
that
all
packets
are
onions
right
and
they
are
just
you
know,
sort
of
a
series
of
layers.
The
packet
builder
is
like
a
single
layer
of
the
onion,
nothing
inside
of
it,
nothing
outside
of
it
just
one
sort
of
shell
right
and
it
assumes
that
we
already
have
a
buffer
allocated.
A
That
already
has
enough
prefix
space
to
serialize.
Everything
will
solve
that
problem
later
and
what
it
does
is
it
serializes
itself
into
the
buffer,
so
you
give
it
a
buffer
like
this.
So
here's
a
buffer
that
has
a
body-
and
you
say,
dear
packet
builder,
so
in
this
case
an
Ethernet
packet
builder.
Please
serialize
yourself
right
here
right.
We
already
gave
you
the
body.
A
We
gave
you
enough
space
just
write
yourself
in
right,
and
so
this
contains
all
the
metadata
needed
to
figure
out
what
that
header
needs
to
look
like
source
address
destination
address
so
on
and
so
forth,
so
that
handles
just
a
layer
of
the
onion.
Let's
talk
about
the
whole
onion
itself,
so
the
serializer
trait,
on
the
other
hand,
represents
the
entire
onion.
So
it
represents
the
you
know,
a
single
layer
and
everything
below
it
and
it's
recursive.
A
So
if
you
take
a
serializer
which
represents
the
whole
onion
and
you
add
a
packet
builder,
which
represents
the
next
layer
of
the
onion,
you
get
a
bigger
onion,
and
this
is
how
we're
going
to
construct
all
of
our
serializers.
Another
important
thing
to
note
here:
a
serializer
does
not
actually
represent
a
packet
directly.
You
can
sort
of
think
of
it
like
a
packet
future.
It
describes
all
of
the
information
necessary
to
figure
out
how
to
allocate
and
serialize
a
packet
in
the
future.
Later,
let's
walk
through
a
very
simple
example.
A
So
this
is
a
sort
of
silly
straw,
man
example
of
a
function
that
might
construct
a
serializer.
It
takes
to
serialize
err
in
and
then
wraps
it
in
IP
and
wraps
that
in
Ethernet
and
then
return.
So
we
start
off
with
a
serializer
called
CERN.
We
encapsulate
it
in
a
new
IP
packet
builder.
Remember
that
builder
is
then
the
IP
layer
of
the
onion,
and
we
get
a
new,
larger
onion
back
right,
a
new,
larger
serializer.
Then
we
encapsulate
it
again
by
adding
yet
another
field,
which
is
this
Ethernet
packet
builder.
A
A
So
the
way
that
we
do
this
is
with
this
serializer
trade
again,
and
there
is
a
method
on
the
serializer
trait
called
serialize
I'm
good
at
naming.
The
serialize
err
is
we're
supposed.
Serialize
method
is
responsible
for
producing
a
buffer.
So
when
you
call
it
it
doesn't
take
an
existing
buffer,
it
actually
creates
and
gives
you
back
the
buffer
and
it
you
know
it
might
use.
You
know
a
pool
of
buffers
or
it
might
use
something.
A
A
So
it
has
to
give
you
a
buffer
whose
body
contains
all
of
the
stuff
that
the
innermost
packet
needs
to
contain,
and
that
has
enough
prefix
length
to
handle
all
of
the
headers
that
came
before
it
that
you're
going
to
need
to
serialize
in
the
future,
and
so
once
you're
in
that
innermost
onion
and
you
have
satisfied
the
request.
You
have
a
big
buffer,
it
has
the
body
and
so
on.
Then
you
can
return
it,
and
now
you
start
walking
your
way
out.
A
So
remember
we
went
in
calculating
the
prefix
length
and
then
you
walk
out
and
actually
serialize
stuff.
So
you
go
to
the
first
layer,
serialize
first
header
right
and
then
you
expand
the
body.
So
now
the
body
can,
you
know,
encapsulate
the
entire
next
packet.
Then
you
return
it
again
in
the
next
player,
serializes,
its
header
and
so
on
and
so
forth,
and
by
doing
this
you
make
sure
that
you
can
just
serialize
in
one
shot
right.
You
allocate
once
you
serialize
once
and
you're
done.
A
A
So
it
has
all
of
the
body
bytes
that
the
application
asked
us
to
send,
and
it
has
that
packet
builder
for
the
UDP
layer
right
that
shell
of
the
onion
that
just
represents
all
the
stuff
that
needs
to
go
in
the
UDP
header,
and
so
when
we
want
to
send
this
we're
gonna
call
this
into
the
send
IP
packet
function.
We're
gonna
pass
it
by
value
right
this
time
you
little
struct
moves
from
this
struct
rate.
Sorry
from
this
stack
frame
to
this
stack
frame,
but
the
body
itself
again
doesn't
move
we're.
A
Gonna
shrink
this
just
for
brevity,
because
we're
gonna
need
to
make
these
slides
pretty
big.
So
that
thing
is
the
same
thing
as
that
thing:
the
IP
packet.
Sorry,
the
send
IP
packet
function
then,
is
going
to
calculate
its
own
routing
information
right.
It
needs
to
figure
out
where
this
stuff
is
going
so
on
and
so
forth,
and
on
that
basis,
it's
going
to
construct
an
IP
packet
builder
for
the
IP
layer
of
the
onion
and
boom
construct.
A
bigger,
serializer
write.
The
IP
packet
builder
represents
the
IP
layer
of
the
onion.
A
This
entire
serializer
represents
the
entire
IP
packet
and
everything
inside
of
it
again
send
it
to
the
next
layer
so
send
it
to
the
send
Ethernet
packet
function,
compress
for
brevity,
take
this
serializer
and
encapsulate
it
with
ethernet.
Right
so
add
another
layer,
the
onion.
Now
we
have
the
Ethernet
onion
alright.
So
now
we've
actually
constructed
this
entire
thing
and
we're
ready
to
serialize
it.
Let's
see
how
that
works.
A
A
So
the
first
thing
that
we're
gonna
do
is
call
serialize
zero
right.
The
outermost
layer
is
the
outermost
layer.
So
we
don't
need
any
prefix
bytes
ahead
of
it
and
we're
going
to
figure
out
how
many
extra
prefix
bytes
we
need
for
this
layer.
When
we
call
serialize
into
the
next
layer,
we
have
to
figure
out
how
many
bytes
the
Ethernet
header
is
going
to
take
up.
So
we
ask
it.
We
say
dear
Ethernet
packet
builder.
How
many
bytes
will
you
need,
and
it
says
18,
so
we
go
okay,
great,
we
needed
0.
A
Now
we
need
18,
so
we
need
18
in
total
and
again
the
next,
the
next
innermost
packet
or
sorry,
the
next,
inter
most
serializer
this
one
for
the
IP
layer
goes
ok
well,
I'm
supposed
to
give
this
person
18
my
layer
itself,
the
IP
layer
right,
the
IP
header
is
20
bytes
long,
so
I
need
an
extra
20
bytes.
So
now
I
need
38
bytes.
In
total,
the
UDP
layer
adds
another
8
bytes.
A
So
now
in
total,
it's
46,
but
now
we're
in
the
middle
right
we've
actually
gotten
into
the
inner
serializer,
and
there
are
no
more
serializers
to
do.
We
can't
recurse
anymore,
so
we
actually
have
to
allocate
the
thing.
So
first
we
have
to
figure
out
how
long
the
body
is.
So,
let's
say
it's
a
thousand
bytes
and
now
we
know
that
we
need
a
thousand
46
bytes,
so
we
allocate
them
again,
we'll
stack,
allocate
later
for
the
time
being,
we're
doing
it
on
the
heap.
A
We
say:
please
give
us
a
buffer
which
is
a
thousand
46
bytes
long
and
that
buffer
starts
off
entirely
as
prefixed,
because
there's
nothing
we
haven't
serialized
anything
yet
so
the
body
is
completely
empty.
There's
there's
nothing
there.
So
first
we
serialize
the
body
that
we
were
asked
to
into
the
buffer.
So
now
the
body
of
the
buffer
is
the
same
thing
as
the
body
of
the
UDP
packet,
and
now
we
can
start
rewinding
back
out
right,
unwinding
out
the
stack.
So
first
we
go
to
the
UDP
packet
builder
and
we
say:
hey.
A
You
know
how
to
serialize
a
header.
Can
you
serialize
yourself
into
this
buffer?
Please
and
it
does,
and
it
expands
the
body
so
that
now
the
body
contains
both
the
UDP
packet
body
and
the
UDP
packet
header,
it's
an
entire
UDP
packet,
and
now
we're
done
this
call
to
serialize.
Has
satisfied
its
constraint
right,
it
was
asked
to
give
a
buffer
which
contains
the
entire
UDP
packet
and
38
bytes
of
prefix.
Well,
we
have
that
so
we
can
return
it
now.
This
next
call
to
serialize
does
the
exact
same
thing.
It
goes.
A
Ok,
great
I
have
a
packet
whose
body
is
what
it
needs
to
be
already.
There
is
enough
prefix
space,
so
I
will
now
serialize
the
IP
layer
in
place
and
again
now
the
body
contains
the
entire
IP
packet
and
has
18
bytes
of
prefix
space.
So
we
can
return
that.
Finally,
we
can
serialize
the
ethernet
layer,
and
now
the
body
contains
the
entire
Ethernet
packet.
Thank
you.
A
A
So
the
goal
this
time
is
first
of
all,
no
heap
allocation.
We're
actually
gonna
allocate
on
the
stack,
we're
gonna
receive
an
Ethernet
packet,
we're
gonna
parse
it
we're
gonna
parse
the
IP
packet
inside
of
it
we're
going
to
decide
that
we
want
to
forward
the
packet
so
we're
gonna,
resize
it
and
send
it
to
somebody
else.
So,
first
we
have
to
update
the
header.
There
are
some
modifications
that
we
have
to
make
to
the
header.
Then
we
have
to
serialize
it
in
a
new
Ethernet
packet,
all
right,
so,
let's
get
into
it.
A
So
parsing
is
super
easy
right.
We
saw
in
the
parsing
section
how
this
works.
There's
gonna
be
super
straightforward.
Again
we
have
the
buffer,
the
actual
bytes
of
it
live
on
the
stack
we
send
it
into
the
receive
Ethernet
packet
function.
We
parse
creating
one
of
these
Ethernet
packet
objects,
which
consumes
those
bytes
from
the
prefix.
We
drop
the
thing,
so
we
can
continue
operating
on
it
and
we
send
the
buffer
into
the
receive
IP
packet
function.
A
Again
we
parse
this
time
getting
an
IP
packet
struct,
and
so
now
we
have
to
modify
this
stuff
in
place.
So
this
is
where
it
gets
interesting,
because
the
modifications
that
we
need
to
do
operate
on
the
sort
of
like
logical
structure
of
the
IP
header.
So
it's
really
important
that
this
header
is
structured
and
gives
us
access
to
like
struct
fields
and
stuff
like
that
for
us
to
be
able
to
update
it,
and
so
the
updates
that
we're
going
to
do
are
actually
methods
on
the
IP
packet
object.
A
So
here's
some
code,
it's
very
simple.
We
just
say
packet,
please
decrement
your
TTL,
which
is
like
a
counter
of
how
many
hops
the
packet
has
gone
through
and
that
just
vanilla,
Roscoe
right,
it's
struct
that
field,
minus
minus
or
minus
equals
1.
Sorry!
And
yes,
so
it's
just
you
know
it's
just
just
normal
normal
Russ
code.
So
now
we
have
this
thing.
Now
we
drop
this
thing.
It's
a
little
bit
of
a
problem
here.
Does
anyone
spot
the
problem
if
we
want
to
serialize
the
IP
packet.
A
Well,
so
the
body
hasn't
been
modified,
but
importantly,
the
body
is
the
body
of
the
IP
packet.
We
don't
want
to.
We
don't
want
to
forward
the
body
of
the
IP
packet.
We
want
to
forward
the
whole
IP
packet,
including
the
header,
but
we
just
parsed
the
header
and
threw
it
away.
So
there's
this
cute
little
hack
that
we
do
it's
very
straightforward.
It's
called
undo
parse.
A
We
say
how
many
header
bytes.
Did
you
just
parse
oops,
please
undo
it,
and
so
we
do.
It
just
takes
the
pointer
and
goes.
Oh
you
just
parse
20
bytes,
okay,
whoops
Bumba,
20
bytes.
So
we
go
from
that
to
that
and
now
we
have
an
IP
packet
that
we
can
forward,
and
so
let's
do
that
right.
So
we
decrement
the
TTL.
We
figure
out
how
many
header
bytes
we
need
to
undo
and
we
undo
them
and
then
we
serialized
very
straightforward.
A
Now
you
might
be
wondering
I
thought
that
send
ethernet
packet
was
supposed
to
take
a
serializer.
Well,
it
is
here's.
The
core
idea
that
I
want
to
get
across
buffers
are
serializers.
The
serializer
trait
simply
says:
can
you
give
me
a
buffer
that
has
these
properties?
If
the
buffer
already
has
those
properties,
then
it
says
yes,
Here
I.
Am
it
just
returns
itself
by
value
right?
The
serialized
method,
you
might
have
noticed
if
you
were
looking
closely
takes
the
serializer
by
value,
takes
it
by
ownership.
So
you
basically
take
this
buffer.
A
You
say
by
buffer
give
me
a
buffer
and
it
says
I'm
already
here:
Here
I
am
back
and
that's
what
we're
gonna
do
so.
First
we
take
the
buffer.
We
send
it
in
to
receive
IP
packet
that
receive
IP
packet
function.
Sorry,
sorry,
excuse
me
we're
in
receive
IP
packet.
Currently
we
send
it
in
to
send
Ethernet
packet.
Send
Ethernet
packet
then
says:
okay,
great.
Here's,
a
serializer
I
need
to
now
encapsulate
it
inside
of
Ethernet,
so
we
do
write
construct
the
serializer
I'm
gonna
squash.
These
stack
frames
just
for
brevity.
A
So
then
the
sending
thir
net
packet
function
says:
okay,
great
I've
got
my
serializer
and
I
need
to
serialize,
so
we
call
serialize
of
0.
We
want
to
serialize
this
thing.
It
says:
ok,
Ethernet
header
asks
for
18
bytes
in
the
prefix,
so
we'll
ask
for
serialize
18
of
our
serializer.
Now
the
buffer
is
the
serializer,
so
the
buffer
looks
at
itself
and
goes
well.
I
already
have
18
bytes,
so
we're
done
and
it
returns
itself
by
value
and
the
the
call
to
serialize
zero
goes.
A
Okay,
great
I
have
a
buffer
that
has
18
bytes
of
prefix
space.
I
can
just
serialize
this
header
directly
in
place.
Then
we
have
finally
a
buffer
which
is
still
on
the
stack
we
haven't
ever
copied
it.
It
contains
all
of
the
bytes
of
the
Ethernet
packet
and
we
can
just
send
this
thing
right.
So
we've
gone
from
having
a
formula
from
receiving
the
packet
on
the
on
the
stack
to
send
the
stack
parse
it
all.
The
way
we've
decided
that
we
want
to
risa
realize
we've
gone
hey.
We
already
have
this
buffer
space.
A
Why
don't
we
just
reuse
it
and
we
reuse
it?
And
finally,
we
can
turn
around
go
okay,
great,
let's
just
forward
it
out.
So
this
is
what
forwarding
looks
like,
and
this
is
sort
of
like
you
know.
This
is
this.
Is
it
this
is
as
simple
as
it
gets,
there's
obviously,
in
practice
a
little
bit
more
complicated
logic,
cuz.
A
A
Alright,
so
that
was
all
about
how
we
do
parsing
serialization
I
mentioned
at
the
very
beginning
that
our
header
references
are
actually
struct
references
which
you
might
have
said
how
the
hell
do
you
do
that,
and
the
answer
is
unsafe
right.
So
this
diagram
actually
looks
like
this
diagram
right.
It's
just
like
that's
a
header
reference.
So
the
way
that
we
do
this
is
with
an
unsafe
marker,
trait
called
from
bytes
and
from
bytes
if
they
type
implements
from
bytes
it
promises
to
satisfy
the
following
properties.
A
First,
it's
any
size
of
T
bytes,
any
sequence
of
bytes
size
of
T
long
is
a
valid
instance
of
this
type.
What
that
means
is
that
I
can
take
random
bytes,
that
I
got
off
the
network
and
just
go.
This
is
a
thing
now
right
now,
you're
just
treated
as
a
thing.
This
is
not
true
of
all
types
right.
If
I
take
a
random
sequence
of
eight
bytes
and
I
say
this
is
a
reference
now
that
is
not
guaranteed
to
be
a
valid
reference
right.
A
It
might
just
point
you
know
randomly
into
memory
somewhere,
so
it's
important
that
this
only
actually
applies
to
a
subset
of
type.
So
we
have
to
be
very
careful
about
which
types
we
apply
this
to
for
composite
types
like
structs
and
arrays
and
unions,
all
the
fields
where
the
elements
have
to
be
just
you
know,
recursively
from
bytes
it
just
composes
nicely
and
then,
if
you
really
want
for
enums,
they
must
be
C
like
and
have
a
power
of
two
number
of
variants
exercise
to
the
reader.
Why
that's
true
all
right?
A
A
So
that's
one
thing
next
thing
is
the
unaligned
train,
so
the
unlined
trait
says
that
something
is
this
is
this?
Is
this
is
fantastic
yeah,
so
the
gun
line
trait
says
that
something
is
on
line
again:
I'm,
fantastic
naming,
and
so
you
can
slap
a
drive
on
something
and
say
great.
This
thing
is
on
line
cool,
it's
important
to
note
that
this
has
some
little
wonky
implications
such
as
like
this
ether
type
field
really
should
be
au
16,
but
it
can't
because
u
16s
are
not
on
the
line.
They
have
an
alignment
of
two.
A
So
it's
a
little
bit
of
like
you
have
to
use
some
some.
You
know
like
byte
order,
type
stuff.
It's
super
simple,
but
it's
kind
of
annoying
anyway,
so
it
has
to
be
on
the
line
because
we
don't
know
where
in
the
buffer
we
might
be.
You
know
parsing
something
from
so
once
we
have
those
two
things
we
can
build.
This
awesome
function
now
this
function
doesn't
literally
exist
in
the
code
base,
but
there's
something
very
analogous
to
it
and
basically
what
it
does.
It's
called
ref
from
bytes.
A
You
say
here
is
a
sequence
of
bytes
of
the
appropriate
length.
If
it
is
not
of
the
appropriate
length,
then
we
return
none,
but
if
it
is
of
the
appropriate
length,
then
it
just
gives
us
back
a
reference
to
T,
because
the
type
system
already
took
care
of
making
sure
that
all
this
stuff
was
safe.
So
we
don't
have
to
do
any
work
at
runtime
right
like
ideally,
this
function
compiles
to
nothing.
This
function
shouldn't
actually
have
a
run
right,
but
it's
a
place
for
us
to
write
the
unsafe
keyword
and
what
it
does
is.
A
It
just
says:
here's
bytes
here's,
a
T
cool
right,
everything's,
safe
the
compiler
verified
it
for
us.
What
this
allows
us
to
do
is
build
this
really
cool
function
and
which
uses
one
of
my
favorite
favorite
favorite
methods
from
the
entire
library
or
from
the
entire
code
base.
So
this
is
actually
the
parsing
function
that
we
really
have
in
the
ethernet
stack.
It's
stripped
down
there,
so
I
remove
some
error
handling,
but
we
had
this
function.
This
method
called
take
objects.
A
It
is
a
method
on
buffer
and
it
says
the
following:
consume
size
of
T
bytes
from
the
buffer
write.
Add
them
from
the
body
to
the
prefix
reinterpret
them
as
though
it
was
a
reference
to
T
and
return
that
reference
and
so
parsing
then
just
becomes
okay.
You
have
a
header,
it
is
a
struct
right,
your
the
header,
struct
cool.
Take
it
done,
that's
all
parsing,
so
this
is
literally
what
the
Ethernet
parsing
function
looks
like.
Similarly,
for
all
the
other
parsers,
it's
basically
just
take
a
struct.
A
Take
a
struct,
take
a
struct
done
and
from
here
on
out
by
the
way
right.
This
is
a
structured
reference.
So
now
we
can
just
access
it.
We
can
say
you
know
header
or
smack
or
you
know
whatever.
So
that's
all
I've
got
so
the
conclusions
from
all
of
this
again,
as
I
said
at
the
beginning,
in
CN
C++,
you
can
absolutely
do
this
stuff.
A
Some
of
you
probably
know
what
I'm
referring
to
here
famously
parallel
CSS
layout,
computation
in
chrome,
was
attempted
a
number
of
times
and
was
never
done
because
they
just
couldn't
iron
out
all
of
the
bugs
in
parallel
C++
code.
It
was
just
too
hard
Chris.
It
exists
in
Firefox.
Why?
Because
it's
written
in
rust
and.
A
So
the
takeaway
that
I
want
to
leave
you
with
is
that
safety
brings
speed
and
developer
friendliness
right
when
I'm
working
on
this
codebase
I
can
move
quickly.
All
of
the
other
developers
that
I
work
with
they
can
move
quickly
because
we're
not
afraid
that
we're
going
to
accidentally
invalidate
some
subtle
invariant
on
a
list
of
invariants
that
isn't
actually
written
down
anywhere
and
it's
developer
friendly
right,
because
when
we
get
new
people
to
the
codebase,
in
fact,
I
think
a
majority
of
the
developers
that
we
have
on
this
codebase.
A
This
is
their
first
rust
project
and
what
that
means
is
that
they
can
come
to
this
project
and
they
can
say:
okay,
I,
like
this,
you
know
little
from
bite.
Stuff
is
terrifying,
but
the
rest
of
the
codebase
is
fine
right.
It's
all
safe,
there's,
no
unsafe
I!
Don't
have
to
worry
about
keeping
all
of
these
invariants
in
mind.
I
can
just
hack
on
the
thing,
and
they
do
so.
That's
all
I've
got
here
are
some
code
links
this
last.