►
From YouTube: Kubernetes Networking Infrastructure...- D Daly & N Jain, N Bitar, Moshe Levi, Vytautas Valancius
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes Networking Infrastructure Offload - Dan Daly & Nupur Jain, Intel; Nabil Bitar, Bloomberg; Moshe Levi, Nvidia; Vytautas (Valas) Valancius, Google
Speakers: Nabil Bitar, Dan Daly, Moshe Levi, Vytautas (Valas) Valancius, Nupur Jain
Networking is central to Kubernetes, as it enables secure and deterministic scale out. As the number of services, pods, and interconnections increases, the kernel overhead will use more compute cycles, thereby lowering throughput and increasing latencies. Infrastructure Offload moves the Kubernetes cluster network policy, routing, and load balancing rules off of the compute platform and into the infrastructure. The cloud provider can then optimize these operations in software or in programmable hardware, such as an IPU or DPU, without requiring any changes to the end user’s applications. In this panel, we discuss various approaches that share a common methodology based on existing Kubernetes APIs to improve performance, free up compute cycles, and preserve compatibility with existing cloud native applications.
A
All
right
good
afternoon,
we
made
it
through
the
through
the
week,
so
today
we're
going
to
talk
about
kubernetes
networking,
but
an
infrastructure
offload
for
kubernetes
networking.
So
we've
assembled
a
panel
of
folks
from
different
areas
to
talk
about
how
do
we
even
just
Define
what
it
means
to
do
an
infrastructure
offload,
and
how
do
we
do
that
infrastructure
offload
in
lots
of
different
contexts?
Are
we
doing
an
infrastructure
offload
in
the
public
Cloud?
A
So
open
programmable
infrastructure
uses
that
infrastructure
word.
It's
really
generic
of
a
word.
What
do
we
mean
in
this
context
when
we're
talking
about
infrastructure
in
this
case
is
that
we
are
taking
the
business
logic
or
the
worker
logic
that's
running
and
we're
going
to
provide
certain
services
again.
Another
overloaded
word
we're
going
to
provide
certain
functions
to
that
worker
node
in
the
case
of
infrastructure,
we're
thinking
of
it
at
a
baseline
as
infrastructure
as
a
service,
so
I'm
going
to
provide
it
a
little
bit
of
networking
a
little
bit
of
storage.
A
Maybe
there's
a
little
bit
of
acceleration
that
we're
providing
so
we're
providing
these
sort
of
basic
abstractions
that
you
would
get
from
a
cloud
and
we
call
all
of
that
infrastructure.
We
group
it
together,
and
so
when
we
want
to
talk
about
software-defined
infrastructure,
that's
what
we
mean.
It's
software-defined,
networking,
software-defined
storage,
all
grouped
together
as
one
and
so
in
this
space
of
programmable
infrastructure,
we're
trying
to
define
the
dividing
line
between
what
is
the
business
logic.
What
is
the?
What
is
the
function
running
in
your
pods?
A
And
why
are
we
creating
this?
New
separation
is
because
you
know
we
think
that
this
abstraction,
which
has
already
been
you,
know
really
useful
in
infrastructure
as
a
service
gives
us
a
bunch
of
great
features
that
we
can
then
apply
to
kubernetes
networking.
So
the
first
one
is
the
idea
of
having
a
gap
for
security
reasons
between
your
logic,
that's
running
and
all
of
the
other
logic.
That's
supporting
it
and
we
call
this
the
air
gap.
A
But
when
this
is
implemented
using
Hardware
functions,
then
we
can
give
Hardware
isolation
to
the
the
work
logic
running
inside
a
server.
The
second
functionality
that
we're
looking
for
is
to
be
able
to
start
moving
tasks
that
may
be
using
Cycles,
creating
latency
or
Jitter,
or
just
sort
of
getting
in
the
way
of
things.
That's
currently
running
alongside
your
worker
work
logic
and
pushing
it
into
the
infrastructure,
and
you
know
initially
to
save
Cycles.
A
A
Maybe
you
implement
it
in
Hardware,
which
is
something
that
we're
going
to
talk
about
today
and
then
in
the
in
the
the
fourth
value
is
once
you
can
re-implement
the
infrastructure
with
a
separate
sort
of
cadence
than
the
the
software
being
loaded
on
the
work
side,
you
can
now
add
features
to
the
infrastructure
a
lot
more
quickly.
So
maybe
you
want
to
change
the
way
the
networking
policy
works
or,
if
you
want
to
add
a
new
sort
of
construct
around
how
your
storage
is
accessed
or
you
want
to
add
computational
storage.
B
Thank
you,
then,
so
we'll
talk
about
what
this
ipudp
or
flowed
and
some
gold
side
requirement
that
we're
looking
to
achieve
from
that.
So
first,
let's
talk
about
what
we
mean
by
offload
from
networking
point
of
view.
So
this
is
usually
mainly
it
targets
really.
The
offload
of
data
plane
processing
functions
from
the
host
CPU
to
the
hardware
neck.
B
That's
what
traditional
offload
meant-
and
this
next
usually
have
been
called
smartnex
or
perform
at
next,
and
they
won't
buy
that
name
with
the
infrastructure,
data
processing
unit
or
data
processing
units
ipus
dpus.
Those
are
considered
as
Evolution
from
the
smartnex
and
and
the
performance
next
to
include
really
a
compute
complex,
which
composed
of
CPU
and
memory,
in
addition
to
Asic
fpga,
usually
for
the
Fastback
processing.
Depending
on
the
implementation.
B
So
what
are
what
are
the
objective?
In
doing
so,
obviously,
the
objective
will
be
to
improve
performance
and
performance
is
really
measured,
usually
by
latency
and
and
throughput
that
could
be
achieved
on
the
host.
Some
applications
also
require
very
low
Jitter
as
well.
You
could
you
could
try
to
achieve
that.
The
other
one
is
improved.
Security,
as
then
touched
on,
is
really
provided
via
the
isolation
of
the
infrastructure
from
the
host.
B
In
the
extent
that
that
you'll
have
and
the
way
to
achieve
that
is
because
you're
freeing
up
what
will
be
spent
in
CPU
cycle
and
doing
packed
processing
such
as
doing
forwarding
policy
enforcement
load,
balancing
and
so
forth,
you're
saving
those
CPU
Cycles
by
offloading
that
functionality
to
the
ipudpu
and
you're
freeing
up
for
application
processing,
and
that's
is
what
the
spiritual
purpose
speeds
are
really
built
for.
It
is
the
application
processing
and
the
other
one
is
really
by
doing
so.
B
B
B
You
could
have
FIB
as
a
state
and
the
the
routing
functionality
or
fuel
or
the
foreign
functionality,
as
the
action
that's
taken
in
the
pipeline.
Similar
could
be
said
on
policies
you
could
have
the
policy
states,
meaning
firewall
rules
that
are
maintained
as
state
and
then
you
could
have
the
policy
enforcement
function
done
on
the
iPad
as
an
action
and
so
forth.
I
don't
want
to
go
through
the
list,
but
just
to
give
you
a
flavor,
there
are
many
things
that
could
potentially
be
implemented
on
the
ipdpu.
B
There
is
a
goal
in
here
to
really
look
at
optimizing:
the
control
plane
for
both
compute
and
networking
to
be
fitting
better
to
the
IP
dpu
Paradigm,
and
that
has
not
been
really
considered
before
and
I'll
talk
about
a
potential
way
to
get
that
at
a
high
level
from
a
taxi
point
of
view.
So
what?
What
is
this
really
is
really
to
look
at
what
is
needed
for
the
control
path
between
the
compute
and
network
controllers
to
the
host
and
then
how
to
offload
the
control
or
distribute
the
control
plated
function
between
the
host
CPU?
B
The
target
is
also,
although
in
here,
where
in
the
kubernetes
conference
in
kubecon
the
Target
in
here,
to
be
able
to
support
the
ipdp
and
for
multiple
compute
endpoints
that
could
include
bare
metal.
So
there
are
many
applications
that
run
on
their
metal
to
support
us
compute
endpoints,
that
could
be
visual
machines
and
there
are
many
such
applications
or
to
support
really
parts
or
container
endpoints.
That
could
be
running
work,
notes
that
could
be
either
bare
metals
or
VMS.
B
That's
kind
of
the
scope
of
this
so
I
want
to
go
through
this
diagram.
It
could
take
a
lot
of
time
to
go
through
that
by
itself,
but
to
illustrate
what
we
mean
by
by
data
plane:
functional
distribution
as
well
as
controlled,
plane,
function,
distribution,
so
overall,
functional
distribution
between
the
ipu
and
dpu.
B
You
could
imagine
a
server
or
a
host
and
John
that
has
two
main
blocks:
that
is
a
host
the
host
CPU
and
this
memory
complex,
which
is
the
upper
part
in
blue,
and
then
you
could
have
the
ipu
dpu
as
another
neck
card
plugged
into
the
same
server
host.
Now
that
ipudpu
usually
will
have
its
own
CPU
memory
complex
as
we
talked
about
and
will
have
Hardware
acceleration
for
the
databad
function
that
could
be
implemented
via
ISC
and
fpga.
B
That's
kind
of
the
setting
of
this
now
when
we
talk
about
the
the
again
the
distribution
of
functionalities,
the
One
path
that
could
be
looked
at
that
today.
If
you
have
an
sdn
controller
or
kubernetes
controller
they'll
interact
with
with
equivalent
control
functions,
if
you
will
that
are
run
on
the
host
CPU,
so
offloading
the
that
to
the
ipdpu,
so
that
the
control
path
could
come
from
the
controller.
Let's
say
the
network
controller
to
an
agent
sitting
on
the
ipdpu
that
will
interact
with
the
with
the
centralized
control
plane
and
via
the
offload
function.
B
B
The
other
function
in
here
is
that
in
coordinating
with
the
with
the
with
the
host
CPU
and
that,
how
does
the
offload
engine
that's
running
on
the
ipdpu
will
contain
to
splice
the
data
path,
if
you
will,
with
the
containers
that
are
running
or
the
pods
that
are
running
on
the
whole
CPU.
So
there
is
interaction
that
has
to
go
on
between
the
offload
control
block.
B
On
the
same
on
the
same
host
CPU,
so
everything
will
be
going
via
a
trusted
path
which
is
related
to
the
infrastructure
represented
by
the
ipudpu
rather
than
being
exercised.
If
you
will,
whether
maintaining
state
like
such
as
policies
or
enforcing
that
state
for
the
policy
on
the
hospital
will
be
done
on
the
ipdpu,
now
I'm
not
going
to
delve
into
the
control
path
for
the
compute.
B
But
you
could
you
could
think
about
that
also
going
through
a
trusted
interface,
if
you
will
meaning
it
could
come
from
centralized
kubernetes
controller
and
what
called
kubernetes
master
and
could
go
also
through
ipdpu
and
through
the
agents.
I'll
call
it
agents
for
now
that's
offload
and
unload.
You
could
trigger
the
the
creation,
if
you
will,
of
the
of
the
pods
via
the
runtime
engine
on
the
hospital.
B
So
the
idea
in
here
again
to
create
isolation
between
the
host,
what
your
workload
is
executing
and
the
infrastructure
where
policy
is
routing
and
so
forth,
is
being
enforced
and
do
the
coordination
between
the
two?
That's
an
example
of
what
we
could
done
at
a
high
level
and
that's
what
we're
looking
really
to
start
examining
that
and
what
the
work
that
needs
to
be
done
in
that
space.
Thank
you.
C
C
So
if
you
look
today
at
public
clouds
and
I'm,
mostly
talking
about
Google,
is
that
public
Cloud
today
offload
VPC
networking
to
ipudpu,
so
we
already
have
offloads
right
and
if
you
look
at
the
features
that
we
offload
today,
if
you
try
to
enumerate
them,
it's
usually
routing
policy,
routing
or
some
people
call
it
service,
chaining,
internal
external
load,
balancing
security
policies.
Etc.
C
If
you
don't
look
at
the
set
of
features
that
kubernetes
networking
implements
it's,
we
call
them
sometimes
differently,
but
they're
very
similar,
which
is
you
know,
portraitability
cluster
IP
note
external
IPM,
Network
policies
observability.
So
there
is
a
lot
of
overlap
between
them,
and
so
can
we
actually
then
offload
these
kubernetes
networking
features
perhaps
to
the
same
infrastructure.
We
already
today
offload
the
VPC
networking.
C
Well,
actually,
we
at
least
in
Google.
We
already
offload
some
of
the
features.
It's
not
very
big
set,
but
some
important
features
so,
for
example,
two
examples
that
I
brought
here
is
border
visibility
and
intra
node,
observability
or
visibility.
So
for
point
reachability
we
rely
on
VPC
Network
offloads
to
be
able
to
scale
to
reach,
to
connect
large
number
of
PODS
and
we
can
run
up
to
15
000
nodes
of
you
know:
200
parts
per
node
and
they're
all
going
to
be
able
to
reach
each
other.
C
Even
you
know
during
the
VM
migrations
Etc,
so
it's
all
offloaded
in
VPC
or
internode
visibility
in
in
gke.
We
have
this
feature
where
we
can
Pan
the
traffic,
even
the
ones.
That's
between
pod.
We
could
configure
to
punt
the
traffic
to
go
through
the
hypervisor,
and
so
it's
not
a
kubernetes
feature
per
se,
but
in
terms
of
observability
you
can
effectively
get
observability
features
that
you
get
in
VPC
you
can
get.
C
So
that's
the
that
was
the
current
state,
but
gke
still
relies
heavily
on
on
loaded
implementation
for
most
of
kubernetes
networking.
So
you
know
we're
on
two
proxy
or
data
playing
V2
and
it's
all
running
inside
the
node
and
using
either
iptables
or
ebpf.
So
why
do
we
do
that?
Well
time
to
Market
familiarity?
C
Resource
accounting
is
an
interesting
topic
where
essentially
the
the
users
who
are
heavy.
You
know
Network
policy
users
they'll,
be
essentially
spending
their
Cycles
to
implement
the
network
policies,
but
there
are
very
strong
Tailwinds
to
offload
more
so
the
sort
of
set
of
reasons
for
that
there's
numerous,
as
as
we
discussed
in
a
few
previous
slides.
But
what
one
couple
of
things
that
I
I'd
like
to
highlight
is:
is
the
maturing
offloads
for
VPC
networking.
Then
it
gives
us
time
to
pay
attention
to
kubernetes
offloads.
C
One
thing
that,
for
me
personally,
is
the
most
important
is
this
feature
velocity
and
we
get
that
feature
velocity
if
we
can
transparently
evolve.
Implementation
of
kubernetes
networking
features
independently
from
the
guest,
OS
and
guest
stack
that
allows
us
to
roll
much
faster
and
then
to
some
somewhat
related.
D
D
D
We
will
review
Nvidia
debut
solution
in
kubernetes,
hello,
everyone.
My
name
is
Moshe
Levy
and
I'm,
a
techlet
that
didn't
media
in
this
part
of
the
panel.
We
will
review
Nvidia
debut
solution
in
kubernetes.
This
solution
is
based
on
open
source
project
and
it's
already
used
in
production
at
Nvidia
internal
projects.
D
Taking
a
closer
look
at
the
work
and
load
with
the
regular
Nick,
we
can
see
that
it
uses
vth
belt
for
the
networking
the
ovs
OV
components
are
running
at
the
worker
node
in
case
of
a
high
packet
rate.
We
will
see
ICP
utilization,
that
we
are
limited
to
a
candle
performance
when
we're
adding
dpu
to
the
cluster.
D
We
are
moving
to
an
esterio
V
switch.
The
networking
as
I
will
be
switch.
Dev
allows
us
to
create
new
device
and
the
working
load
to
give
to
the
Pod
and
appear
on
a
device
which
we
call
a
buffer
presenter
to
plug
to
the
obs.
Also,
obviously,
we
are
now
no
longer
running
at
the
worker
mode.
They
move
to
the
dpu.
So
all
the
OV
and
obvious
control
plane
is
now
at
the
dpu
level.
D
Also
in
case
of
I
packet
rate,
we
will
see
low
performance
utilization
because
all
the
packet
processing
is
now
in
the
GPU,
also
from
a
security
and
isolation
perspective.
If
the
worker
mode
is
compromised
and
try,
it
cannot
tamper
with
the
networking,
because
all
the
networking
control
plane
is
moved
to
the
dpu
and
the
dpu
on
the
master
are
in
the
trust
domain
and
now
a
little
bit
on
how
we
do
dpu
Hardware
acceleration.
D
So
we
are
leveraging
leveraging
SRV
switch
Dev
technology,
obvious,
open
source,
already
support
Sr,
we
switch
them
and
it
knows
how
to
program
the
e-switch
connect
when
the
first
packet
arrive
into
the
obs
obvious
itself
is
using
standard
kernel.
Api,
there's
nothing
proprietary
here,
which
is
a
tcflower
to
program.
The
heat
switch
in
case
the
how
dual
vendor
doesn't
know
how
to
accelerate
the
packet.
D
D
Is
a
data
performance
that
we
run
and
experiment
in
Nvidia
lab?
Here
we
have,
we
are
using
xci
as
a
package
emulator.
We
have
the
host
details
of
the
input
CPUs.
On
the
left
side,
we
have
obvious
learning
connecting
6
LX,
dual
pod
25
gig
vth.
On
the
right
side,
you
have
obvious
accelerated
with
Bluefield
2,
dual
pod
25
gig
running
siob.
D
D
D
Linear
performance,
a
50
gig
with
siob,
also
from
latency
perspective,
you
get
four
time
late,
better
latency,
when
using
a
style.
Now
to
summarize
it
so
with
dpu,
we
get
uncompromised
performance
in
case
of
nvida
dpu.
We
can
offload
and
accelerate
all
the
kubernetes
flows
put
to
part
to
the
service,
while
reducing
CPU
utilization
to
Bell
minimum.
From
the
security
aspect,
we
have
networking
isolation
if
the
host
is
tempered.
This
solution
is
good
for
boards,
for
VMS
and
for
Bare
metals
and
dpu
is
a
commodity
project
running
a
plane
Linux.
E
F
My
name
is
lupujan
and
I'm
part
of
Intel
ipdk
team
I
have
already
emphasized
on
the
importance
of
infrastructure
offload
and
other
implementation
Solutions.
Let
me
go
over
how
we
are
doing
it
to
move
from
the
traditional
deployment
model.
As
shown
on
the
left
to
infrastructure
offload
model
for
various
Cloud
deployment
scenarios.
We
need
dedicated
interfaces
to
the
parts.
With
this
we
can
offload
Elder,
switching
L3
routing
service
load,
balancing
which
includes.
F
To
move
from
the
traditional
deployment
model,
as
shown
on
the
left
to
infrastructure
offload
model
for
various
Cloud
deployment
scenarios,
we
need
dedicated
interfaces
to
the
parts.
With
this
we
can
upload
L2,
switching
and
free
routing
service
load,
balancing
which
includes
CT
and
AD
functionality,
encapsulation
and
encryption
to
our
extensible
data
plane.
We
added
a
new
P4
based
lean
data
plane
to
calculus
Edition
p
for
programmability,
makes
the
data
plane
extensible
to
Future
Cloud,
use
cases
and
provides
for
better
visibility
into
flow
treatment
through
counters
and
stats.
F
Calico
supports
a
broad
range
of
platforms,
including
kubernetes
and
openstack,
and
others
for
deployment
of
parts
and
VMS.
It
also
supports
multiple
datablings
using
eppf
and
IP
tables.
Our
day.
Plane
offers
two
ways
forward
for
Accelerated
functionality,
for
better
free
for
better
performance
and
reduce
latencies,
a
software-based
data
plate
which
is
implemented
using
dpdk
and
a
hardware-based
solution
using
ipu
since
control
plane
components
are
similar
in
both
of
these
models
and
offer
a
loose
coupling
for
communication
using
well-defined
interfaces.
The
same
control
plane
works
for
the
above
two
and
other
Calico
Solutions.
F
This
helps
with
interoperability
across
data
center
nodes,
with
a
mix
of
accelerated
and
non-accelerated
nodes.
Here's
a
picture
that
goes
a
bit
deeper
into
the
architecture.
The
data
plane
drivers
split
into
two
components.
Each
antenna
manager,
which
communicate
using
grpc
agent,
can
be
further
split
up
into
no
region.
An
infra
agent,
while
manager
running
on
the
infrastructure,
manages
the
resources,
life
cycle
of
the
components
and
offload
three
runtime
rules.
The
node
agent
receives
the
cni
calls
as
interfaces
to
the
parts
on
the
host.
F
F
Biggest
advantage
of
infrastructure
offload
is
that
it
offers
a
secure
environment
for
configuration
of
resources
away
from
compute
where
ports
are
running.
It
also
provides
a
secure
access
to
other
infrastructure
provisioning
pieces
like
storage,
the
scalability
performance
and
reduce
latencies.
While
freeing
up
the
host
cores
are
the
highlights
because
of
this
kernel
bypass,
it
provides
for
better
feature
velocity
as
well.
F
Here's
a
running
example
deployment
with
our
components.
As
you
can
see,
we
have
interest
manager
and
Enterprise
agent
running
as
Team
sets
and
together
they
are
provisioning.
The
dpdk
pipeline,
with
rules
just
to
show
a
B,
for
example,
of
this
implementation.
We
have
service
load,
balancing
implemented
using
P4.
Here
the
this
implementation
uses
connection
tracker
and
that
functionality,
the
very
first
packet,
is
looked
up,
and
it's
used
to
pick
one
of
the
endpoints
from
the
service
web
pool.
F
Once
the
endpoint
has
been
picked
up,
the
flow
is
added
to
connection
tracker
and
the
subsequent
packets
are
up
into
the
same
endpoint,
and
that
is
applied
to
learn
more
about
this
implementation
and
how
other
sample
examples
have
been
implemented.
Please
go
to
ipdk.io,
create
a
simple
offload
where
we
are
working
on
the
recipe
and
you
see
more
additions
to
existing
implementation
thanks.
So
much
for
your
time
today,.
A
To
learn
more
about
what
she
just
described
and
also
there's
a
demo
of
the
code,
you
can
also
download
the
code
and
run
it
yourself
at
ipdk.io.
It's
also
part
of
the
OPI
project,
which
I
mentioned
earlier,
which
also
has
a
bunch
of
code
being
developed
to
be
able
to
have
consistent
interfaces
for
these
different
types
of
dpus,
ipus
and
other
acceleration
devices.
A
So,
in
summary,
we
have
heard
from
folks
working
in
public
Cloud
we've.
We
have
heard
from
Moshe
working
on
a
dpu
we've
heard
from
nuper
working
on
ipu
and
there's
a
lot
of
commonality
in
that
the
the
worker
CPU,
the
the
job
that
they're
doing
should
not
be
changed
or
modified
in
any
way.
This
is
a
function
where
we're
pushing
the
infrastructure
underneath
an
abstraction
so
that
the
the
the
end
user
doesn't
need
to
worry
about
it.
There
are
some
things
that
are
required
in
all
these
different
solutions.
A
We
can
use
existing
kubernetes,
apis
and
and
copy
that
state
from
the
worker
CPU
into
the
infrastructure,
to
minimize
the
the
set
of
changes
needed
in
order
to
take
advantage
of
this
offload,
and
so
you
know,
there's
different,
there's
different
options
and
different
implementations
out
there.
We
want
to
have
that
commonality.
We
want
to
be
able
to
have
commonality
across
the
different
ways
that
you
can
deploy
this
technology
and
we
absolutely
want
to
be
able
to
allow
people
to
choose
different
vendors
and
different
implementations.
A
G
G
A
So
I
would
say
that
you
know
these
are
very
programmable
devices
and
they've
been
designed
to
be
able
to.
You
know,
understand
the
the
state
of
the
art
in
terms
of
kubernetes
networking
and
it's
really
similar
or
maybe
a
a
really
similar
to
ebpf,
and
that
we're
we're,
starting
with
something
like
an
iptables
and
evpf,
is
an
example
of
using
optimized
software,
but
keeping
it
on
the
worker.
You
could
use
this
technology
and
run
that
functionality
in
the
infrastructure
as
ebpf.
A
C
E
H
A
So
Ellie
speaking
from
the
Intel
ipu,
we
are
agnostic
as
to
the
type
of
interface
you
may
want
to
use
whether
it's
sriv
vertio
ve
we're
flexible.
So
we
we
support
all
of
those
different
types
of
interfaces
and
also
supporting
them.
At
the
same
time,
if
you
have
a
primary
and
secondary
Network,
so
it's
really
a
function
of
of
what
you
have
existing
and
and
and
what
you
want.
Your
network
to
look
like
from
the
worker
CPU
side.
B
B
Optimization
that
you
have
to
do,
for
example,
if
you're
running
on
the
hospital
CPU,
you
don't
have
to
have
the
bandwidth
for
Hardware
acceleration.
You
don't
have
the
security
requirement,
then,
whether
using
ebpf,
as
was
said
earlier,
as
as
a
way
to
implement
probably
the
data
path
in
a
faster
way
than
you
would
have
done
in
iptables.
You
use
that,
if
dptk
will
be
needed
will
still
be
do
that.
You
could
still
do
that.