►
From YouTube: DASH Behavioral Model WG Jan 26 2023
Description
Push ST/PL bmv2 PR308 to next week Feb 2 2023
https://github.com/sonic-net/DASH/pull/308
Q: Andy: match, key gen ID, will this be in P4, per ENI (Y), CP will decide updates (batch or real-time),
will the key gen entries be replaced?
From former HA notes:
It is the implementation - depends upon your hardware and what is optimal for the technology provider. Packet triggered here…
Config level of the VNIC/ENI, change config/policies on the ENI, config version changes from 0 to 'not zero', cache the version for the ENI that is maintained IN the connection, look at version maintained in the connection for the ENI (from when the last packet triggered the fixup), and tells datapath whether an update to the State in the connection is needed, packet will go through policy lookup and update. (For every connection we will have a cached version). Will not transit the EST flow for forwarding…or do we use the flow entry that is there? We don't have to update the flow (per se). Gen ID should make it's way into the P4 code. Andy: Aggressively delete old or let them be aged out? Not sure if this is defined in P4 model.
Hanif: In P4 community, has bmv2 caught up?
Andy: Open Source PLang projects review: majority of code is delivered via paid developers
BMV has been in maintenance mode
Would a switch from bmv2 to dpdk go smoothly today? Likely not… w/reference model & control plane changes (src & dest address list-match-type, etc…) - no simple datapath implementation at high speed. No path into DPDK.
On the other hand, people are working on P4 DPDK (useful, performant, c/be turned commercial). BMV2 is local…
No idea if we have gaps/feature support.
Andy: does it even compile? Gaps? Run through P4C DPDK Compiler.
Chris: workflow? 1) execution engine P4 DPDK 2) Compiler 3) P4 code in behavioral model
P4 code to SAI header file (autogeneration) not platform dependent
libsai IS platform dependent
Volodymyr: https://github.com/p4lang/p4-dpdk-target and https://github.com/p4lang/p4-dpdk-target/tree/main/examples/pna
Reshma: TDI integrating into sync_d of SONiC as a direct call (not an RPC call)
Want to implement DASH onto DPDK
Connection tracking will be DASH connection tracking
range port list and list port list (in bmv2) upstreamed into P4.org? Andy to check? Power of 2 ranges accepted only?
DPDK can be a replacement for bmv2 - may need to make choices in terms of implementation
A
A
No,
no
okay,
yeah
I
mean
so
you
could.
You
could
imagine
somebody
knowing,
like?
Oh
I've,
got
a
few
Jackal
update
and
100
routing
updates
or
something
like
that.
It
could
do
all
those
and
then
bump
the
generation
number
up
once:
okay
and
that's
per
e
and
I,
and
that
basically
means
effectively
when
you
bump,
like
for
eni
57,
if
you
bump
the
generation
up
from
two
to
three
all
the
flow
table
entries
for
Generation,
two
with
eni
64
are
now
going
to
be
missed
and
age
out
and
new
eni
64
generation.
B
C
A
But
is
the
intent
suppose
there's
a
generous
suppose
for
one
particular
flow,
there's
a
generation,
two
entry
and
then
the
generation
for
that
DNA
bumps
up
to
three
and
another
packet
comes
in
for
that
flow?
Is
it
going
to
have
a
key
lookup
exact
match
on
generation
three
and
get
a
miss
and
then
do
the
slow
path
and
add
a
generation,
three
entry
and
the
generation?
Two
entry
is
still
there
aging
out
or
is
that
an
implantation.
A
B
A
A
Like
nothing
in
P4
will
will,
unless
you
do
two
lookups
on
the
same
table
in
P4
one
for
the
current
generation
ID
one
for
the
generation
at
e
minus
one.
You
won't
know.
If
generation
had
D
minus
one
exists
in
the
table
in
the
P4
code.
In
the
data
plane,
for
example,
the
control
plane
could
go
and
scour
them
all
out
when
it
bumps
up
the
generation
ID
it
can
scour
and
remove
all
the
entries
if
it
wants,
but
the
data
plane
itself
won't.
Do
it
right,
except
by
aging.
B
A
A
Have
to
be
implemented,
okay,
but
but
it
sounds
like.
Maybe
this
might
be
a
quality
of
implementation
issue,
whether
you
aggressively
delete
them
or
you
let
agent
take
care
of
it,
which
could
increase
your
tables,
which
increases
the
number
of
entries
you
need
during
that
time.
Yeah,
if
you,
if
you
let
aging
handle
it,.
A
A
C
C
C
B
C
A
C
A
C
A
A
C
C
C
A
C
C
C
B
I
mean
all
the
things
that
basically
so
that
just
wanted
to
see.
If
you
know
I
know
we,
we
have
a
lot
of
items
that
you
know.
People
need
to
pick
up
or
deliver
it
right
in
terms
of
there's
a
big
backlog,
so
to
speak
right.
So
any
progress
on
that
area
that
you
can
talk
about
it
it'll
be
great.
Otherwise,
if
there's
no
progress,
then
I
can
probably
think
that
okay,
we
haven't
made-
you
know
any
inroads
in
there,
but
just
wanted
to
see
if
there
are
any
progress
in
there.
So.
C
There
hasn't
been
a
lot
of
progress
from
the
Microsoft
side.
We've
been
looking
around
for
internal
resources,
who
maybe
know
P4
can
do
P4
reached
out
to
MSR
Microsoft
research,
looking
for
resources
and
people
and
I
think
you
know,
y'all
have
seen
resourcing
issues
with
all
the
tech
companies
lately
and
we
haven't
really
seen
much
progress
there.
So
that's
that's
where
I'm
at
there
I
hope
it
looks
like
Vladimir's.
Here,
sorry
go!
Let
him
in
so.
You
know
the
I
know
that
Marion
had
said
last
week.
C
He
was
focusing
more
on
the
next
feature,
which
is
service
tunnel,
private
link
versus
getting
the.
What
was
it
the
apis
and
the
compiler,
and
all
that?
So
maybe
we
could
talk
to
him
about
that
next
week
and
see
where
we
are,
but
it
seems
like
we
really
only
have
you
know
a
couple
of
active
resources
working
on
it,
foreign.
B
A
D
A
A
Right
now,
behind
on
behavioral
model,
it's
kind
of
been
in
maintenance
mode
and
Antonin
boss
is
at
VMware
and
you
know
has
been
making
bug
fixes
to
it,
but
not
making
I
mean
it's
he's
not
paid
to
make
enhancements
to
it.
I
think
I
think
his
bug
fixes
have
been
mostly.
You
know,
volunteer
time
uninspired.
A
So
anybody
like
it's
open
source.
Anybody
can
enhance
it,
but
the
people
that
tend
to
do
so
even
on
p4c
tend
to
be
people
paid
to
do
it
full
time,
and
nobody
to
my
knowledge
today
at
Intel
is
paid
to
enhance
bnb2,
otherwise,
you'd
notice
it
in
the
open
source
repo.
There
are
people
that,
until
paid
full-time
to
enhance
p4c
and
in
particular
the
dpdk
backend,
there
are
people
paid
full-time
had
like
half
a
dozen
people
or
so
are
paid
to
develop,
to
enhance
the
dpdk
back
end
for
P4
compiler.
A
Does
that
mean
you
could
just
switch
today
from
bmv2
to
dpdk
and
everything
would
go
smoothly?
I
I
really
don't
know,
because
I
know
that
some
of
the
changes,
if
I
understand
correctly,
that
Folks
at
Nvidia
melanox
have
made
the
bmv2
involve
like
these
lists
and
list
Port
match
kinds
in
the
behavioral
model
code,
which
those
are
control
plane.
In
my
mind,
those
are
like
control,
plane
and
reference
model,
only
kind
of
changes
now
they're
good
for
a
reference
model,
they're
good
for
the
control
plane
API
for
dash
they're.
A
Not
they
have
no
direct,
simple,
straightforward
data
plane
implementation
at
high
speed
great
for
a
reference
model
that
you
just
care
about
a
few
hundred
packets
a
second,
so
those
are
not
implemented
in
dpdk.
Nor
do
I
have
any
knowledge
of
anybody
planning
nipple
in
the
dpdk.
But
if
everything
else
is
there
that
folks
want
and
I
know,
there's
Psy
Implement
a
generation
code,
I,
don't
know
if
that's
tied
to
bmv2
or
if
that's
independent
of
bmv2,
maybe
other
people
here
know
anyway.
That's
that's
so
that's
me
spewing
there
for
a
while
I,
don't.
E
I'd,
like
to
I'd
like
to
comment
on
what
you
just
said,
this
is
Chris
the
other
luminary
yep,
so
just
quickly
that
the
list
match
type.
My
understanding
is
that
syntactic
sugar
and
not
a
necessary
part
of
this.
It
could
just
be
solved
by
sending
more
messages
right
from
the
control
plane
because
it
just
it
probably
gets
expanded
out
anyway
in
a
real
implementation
right.
It's
just
it's
just.
A
A
complicated
it's
when
you
have
like
a
source
address,
list
type
and
a
desk
dress
list
type.
The
most
obvious,
straightforward
supplementation
is
to
the
cross
product
of
the
San
Diego
right,
and
that
turns
into
millions
of
entries
in
in
reasonable
size
configurations,
I
think
which
you
could
do
in
a
software
model.
If
you
have
enough
memory
and
it'd
be
fine,
someone's.
E
A
E
E
Model,
so
just
that
with
that
comment
aside,
I
don't
know
of
any
other
obstacles
from
what
you
said,
that
of
switching
to
p4dpdk
and
the
benefits
would
be.
There
are
people
working
on
it.
It's
open
source
as
far
as
I
know,
right,
yeah
everything's,
getting
done
out
in
the
open,
yes
and
and
we'd
have
a
little
more
and
would
have
reuse
right.
It'd
get
a
broad
usage,
whereas
this
bnb2
project
we
have
in
dash
is
very,
let's
say,
local
local.
Well,
no,
it's
very
local.
A
E
A
E
E
A
Want
to
assess
what
the
gaps
are
if
there
are
any
first
before
coming,
okay,
like
like
I,
think
there'd
be
low
chance
of
saying
hey.
Can
you
please
implement
this
list
match
kind?
But
if
we,
you
know,
do
the
kind
of
crossbody
expansion
in
the
control,
plane,
subcontrol,
plane
middle
layer
for
reference
code,
then
they
don't
need
to
do
that.
A
So
then,
the
question
is,
you
know:
what
are
there
any
other
gaps
that
need
covering
and
I
like
I
can
do
a
quick
analysis
from
the
compiler
point
of
view
and
then
like
actually
running
tests.
If
that
goes
well,
then
there's
the
issue
of
just
try
running
the
test
to
make
sure
there's
no
known
bugs
that
in
the
behavior
that
we
see
with
the
code
yeah.
E
So
to
me,
there's
really
three
three
pieces
to
this
puzzle:
one
is
the
execution
engine
right,
the
P40
pdk
itself.
You
know
the
platform,
there's
the
compiler
and
tooling
to
generate
you
know
the
code
for
that
platform
and
then
there's
the
P4
code
in
our
behavioral
model,
which
also
is
not
getting
full
attention
right.
Just
let's
say
we
have
a
perfectly
working
bmv2
that
met
all
of
our
dreams.
E
So
so,
even
if
Andy
comes
and
gives
it
to
us
on
a
silver
platter,
it
doesn't
mean
the
work's
going
to
get
done
beyond
that
right.
So
in
general
we
need
all
these
things
solved,
but
that
seemed
like
P40
BDK
is
getting
closer
to
reality
and
seeing
the
presentations
at
the
P4
workshop
last
year
right,
it's
almost
it's
almost
complete.
A
E
It's
not
a
must,
but
if
we
start
doing
certain
use
cases
like
let's
say:
CI
CC
cicd,
test
K
that
have
more
than
just
a
couple:
packets
right,
we
start
having
meaningful
flows
or
larger
setups.
Bmv2
is
just
gonna.
You
know
collapse
right
under
the
weight
it
could
take
all
night
to
run,
whereas
something
that
can
send
a
million
packets
per
second
or
something
is
going
to
be
much
more
exciting
to
and
useful.
A
But
but
I
just
I
just
warn
you
that
I
won't
be
surprised.
If
there's
you
know
some
gaps
there
that
we
we
should
try
to
scope
out
and
find
with
sure
which
is
hopefully
a
low,
hopefully
low,
effort
to
find
you
know
the
the
low
hanging
fruit
gaps.
If
there
are
any
and
then
there
might
be
some
subtler
ones,
but
if,
if
it
turns
into
cellular
ones,
then
I
suspect,
that's
something.
The
DPT
team
will
want
bug
reports
on
anyway,
yeah
even
just
a
high
level
reality.
E
A
It
it
definitely
should
again
its
implementation.
They
have
bugs
that
are
implemented,
independent
of
bmv2s
limitations
in
that
area,
so
again
something
to
flush
out
and
yeah.
But
again
those
are
the
kind
of
things
if
they're,
just
if
they
don't
involve
new
language
extensions
they're,
the
kind
of
things
they
want
bug
reports
on
anyway.
E
Yeah
and
then
you
know,
there's
always
an
optimization
possibility
if,
if
P40
pdk
uses
the
TDI
layer
internally
could
always
bypass
the
serialization
into
P4
runtime
and
be
more
optimized.
But
that's
that's
a
nice
to
have
like
on
the
Mount
Evans
implementation
right.
It's
natively,
translated
from
my
understanding
from
PSI
into
the
table
driven
interface,
which
is
you
know,
another
Library
binding,
not
a
serialized
interface
like
before
bedtime.
F
So
just
I
heard
about
the
TDI,
so
I
just
want
to
say
that
in
the
soft
switch
that
we
were
working
on,
we
are
basically
integrating
the
programming
layers,
like
TDI
Etc,
directly
into
the
sigdi
of
Sonic
container
as
a
Cindy
container
of
Sonic
wow.
So
it
will
be
a
direct
call.
It
is
not
going
to
be
anything
like
an
extra
RPC
which
we
want
to
avoid.
It
will
all
be
in
the
single
you
know
so.
Yeah.
E
F
A
F
Sure,
thank
you
so
much
so
we
want
to
basically
implement
the
dash
dot
P4
on
dpdk.
That
is
our
goal
at
this
time
and
then
you
know
we
have
already
been
working
on
the
soft
switch
earlier
in
the
a
few
months
ago.
At
that
time
we
had
a
pause,
big
pause
because
we
needed
some
more
functionality
implemented
in
the
P4
dpdk,
but
I
think
we
have
all
that
now,
so
we
could
accelerate
that
yeah
and
and
once
we
Implement
that
we
would
like
to
open
source.
F
Yeah,
so
we
want
to
yeah,
we
have
the
yeah,
the
connection
tracking
will
be
Dash
connection
tracking.
What
we
are
talking
here
is
in
context
of
Dash,
so
Dash
connection
tracking
will
be
implemented
in
the
before
dvdk.
In
the
sense
we
already
have
that
on
misconstruct
implemented
with
that
already
present,
then
it
is
possible
for
us
to
do
this.
It's
very
hard.
A
I
think
maybe
was
I
can
take.
The
latest
version
of
the
P4
code
checked
into
the
Dash
repo
and
just
run
it
with
through
the
p4c
dpdk
compiler
and
see,
if
there's
any
gaps
or
in
its
implementation,
on
support
for
anything
and
report
back
to
other
folks
just
to
get
that
first
passive,
anything
missing
or
not.
F
That
sounds
great
yeah.
Thank
you.
So
much
for
that
yeah
previously
I
think
there
are
some
other
constructs
in
BMV
to
today,
like
the
range
support
list
and
Report
list
for
I
utilized
for
Arcus
Etc,
so
wondering
if
that
can
be
pushed
into
or
Upstream
to
before.org.
If
it
is
useful
for
everyone
from
the
BMV
to
side
as
well.
A
Yeah,
okay,
the
the
range
one
I'll
check
with
Christian
on
deep
DK
to
see
whether
they
implement
it
already
or
not.
I
do
recall
there
being
maybe
a
limitation
there
on
the
current
implementation
that
they
do.
Power
two
ranges
only
on
the
list.
Type
Chris
and
I
talked
about
it
before
you
joined
perhaps,
and
it
might
be
that
the
best
thing
there
would
be
not
to
push
that
into
P40
like
the
language,
spec
or
the
implementation.
But
there's
a
way
to
basically
for
small
enough
configurations.
A
F
C
So
we've
started
talking,
we
we
started
talking
about
it
was
like
is
the
key,
the
key
generation
when
we
were
doing
some
flow
stuff
and
then
we
morphed
into
honey
fast
about,
has
BMV
2
caught
up
in
P4
community,
and
that
started
this
conversation
restaurant.
So
we
didn't,
we
didn't
have
Marian
or
Prince.
Today
they
had
a
conflict
yeah.
F
So
Andy,
as
we
had
spoken
earlier,
and
you
had
pointed
out
the
range
list
and
Report
list-
that's
there
in
bmv2
we
can
discuss.
You
know
if
it
is
beneficial
for
Nvidia
to
sort
of
Upstream
that
or
if
there
is
a
different
version
of
that.
Whatever
we
think
is
a
better
version.
We
should
definitely
ensure
that
gets
into
the
before
org.
A
I
I
guess
quick
question
Chris
or
anybody
here
I
mean
suppose
you
suppose
we
did
the
cross
parking
thing.
So
imagine
there's
the
minor
chain
is:
there's
a
config.
You
could
do
so
you
could
say.
Oh
here's,
a
thousands
Source
address,
prefixes,
here's
a
thousand
destination
address,
prefixes
the
obvious
dead,
simple
way
and
the
control
plane,
middleware
I'm
thinking
that
would
be
produced
to
one
thousand
times.
One
thousand
entries
that
have
one
source
IP
in
desktop
prefix
each
and
matches
the
same
way,
so
that'd
be
a
million.
A
E
Well,
I
guess:
I'll
answer
like
this:
it's
a
lot
better
than
we
have
now
I
see
it's
okay,
not
none,
and
even
if
we
did
Implement
list
match
type
now
in
bmv2,
it
would
never
get
close
to
the
scale
and
performance
of
a
presumptive.
P4
dpdk
up
implementation
right.
So
it's
better
than
nothing
right,
even
if
we
say
well
for
cicc
cicd
and
software
testing
will
limit
ourselves
to
a
total
of
a
million
entries
or
a
hundred
thousand
whatever
we'll
come
up
with
something
that
we
can
live
with.
It's
still
better
than
nothing.
F
A
E
B
Yeah,
no
I
think
you
know
as
long
as
it
basically
allows
us
to
emulate.
You
know
certain
reasonable
number.
Not
we
don't
have
to
basically
probably
scale
up
to
what
the
hardware
might.
You
know
eventually
provide.
Well
one
thing
guys,
you
know.
Maybe
there
is
a
very
simple
answer
to
this
one
or
a
brief
answer
to
this
one,
but
you
know
when,
at
least
in
my
view,
what
I,
whenever
I
look
at
bmv2
I
see
this
is
a
soft
search
and
at
least
my
understanding
was
dpdk
was
not
a
soft
switch.
F
A
B
F
And
oh
dpdk
is
just
a
pipeline
that
runs
in
the
host
right.
There
could
be
other
control
planes
that
is
utilizing
and
writing
to
that
pipeline
in
the
host.
It
could
be
OBS
in
our
case
we
want
it
to
be
Sonic
and
running
Dash
and
the
dash
and
the
pipeline
to
be
Dash,
specific
and
and
Sonic
is
the
control
plane
that
will
be
writing
to
into
that
pipeline.
E
I
mean
dpdk
is
just
a
toolkit
for
writing.
User
mode
data,
plane
programs
right
it's
it's
just
a
like
a
set
of
Frameworks
and
libraries.
You
can
do
anything
in
it
and
and
the
Geniuses
in
Intel
have
been
creating
a
P4
framework,
so
they've
Implement,
all
the
P4
constructs
like
look
up
tables
and
and
registers
and
and
parsers
in
the
dpdk
framework.
B
E
E
You
know
kind
of
a
it's
like
a
it's
kind
of
a
runtime
engine
that
reads
the
Json
file,
which
is
the
output
of
the
p4c
compiler
back
end
and
then
says:
okay,
I'm,
gonna
I.
Have
all
these
capabilities
I'm
going
to
configure
myself
to
be
this
pipeline
based
on
the
Json
file?
Then
it
runs
it.
Dpdk
is
probably
a
lot
more
optimized
I.
It
probably
compiles
more
bespoke
code
based
on
your
P4
program.
I
would
guess.
A
B
B
Behavior
model
and
so
forth
right
when
we
actually
look
at
bmv2
at
least
you
know,
from
the
documentation
point
of
view,
that
it
is
a
soft
switch
as
a
target
for
which
we
have
certain
architectures
before
architectures
Define.
You
know
one
of
them
being
like
V1
model
to
speaker
right.
So
when
it
comes
to
say
dpdk
Target
before
dpdk
Target,
you.