►
From YouTube: SONiC DASH Workgroup Community Meeting Sept 6 2023
Description
Kamil and Chris discussed the issue of the Sai metadata object code being compiled into the Lib Sai library, which is unnecessary for abandoned distros. Kamil proposed a solution of having a separate library for the Sai metadata object code, which Chris agreed to look into.
Implications of removing SAI Meta; Chris explained that the PTF test cases should still work, as the Lib side meta will be separated and linked into the final output. Chris clarified that the PTF test cases will still work, as the libsai meta will be separated and linked into the final output.
Double Decap in PL:
Transformation of packets from the original packet to V6 and then to another layer of encapsulation. Inbound processing and the expectation that the flow is always created by the outbound.
Packet format and VM to VM transposition overview for PL The packet is transformed for each VM on both sides and the return packet is seen in step 15.
Flow lookup for a double encap packet with the note that the innermost header should be used for the flow lookup. Trigger for flow s/be taken offline to discuss further. Also how to handle double encap before doing the flow lookup. Inbound processing is performed in the hardware and that the routing action is double encap. Concluded that two layers of encapsulation need to be passed to expose the innermost packet before the flow lookup can be done.
Meter policy: Prince provided insight on the scale of the table, stating that it is a limited number, not a high scale.
Build repo for the DASH version. The build repo requires hardware libraries; still a WIP.
Removal of P4 from the HLD documentation; decided to keep the documentation in the HLD, but update it to reflect that it is not supported.
A
For
coming
to
the
dash
Community
call
today's
the
83rd
meeting
that
we're
having
so
two
years
ago.
September
is
when
we
fired
up
this
group.
I,
don't
know
if
everyone
remembers,
but
I
do,
and
so
this
last
week,
I
sent
out
some
pretty
verbose
notes,
I
put
them
at
the
top
of
the
fold
just
because
I
thought
they
were
interesting,
but
I
tried
to
cover
everything
we
talked
about,
because
actually
it
was
almost
like
Marian
giving
a
tutorial
in
the
pipeline
in
the
bmv2.
So
I
tried
to
capture
it
all
here.
A
A
Did
you
guys
get
the
notes
sent
out
Muhammad
or
I
received
them?
Okay,
cool
right,
so
this
was
okay,
great
yeah,
so
this
was
awesome
and
then
we
we
talked
about
the
continuing
refinement
work
and
we
requested
to
get
some
clarification
here:
service,
tunneling
and
blah
blah.
So
if
you
know
anyone
who
might
want
to
receive
these
notes,
let
me
know-
and
so
I
guess
Mario
could
tell
me
if
I
got
it
wrong
so
and
then
I
was
wondering,
I
saw
PR
come
through
and
I
was
wondering
Chris
this
week.
A
B
C
Yeah
I
can
talk
about
it
and,
let's
see
because
Camille's
on
the
call
too,
which
is
just
intersects.
Some
of
the
improvements
he's
been
making,
which
you
know
he
kind
of
helped
pave
the
way
to.
Let's
say,
final
good
conclusion.
But
basically
you
know
some
vendors
were
pointing
out.
I.
Think
I.
Think
the
start
with
Vincent's
observations
at
excite
that
the
side,
the
dash
side,
Thrift
library,
has
some
side
meta
object
code
compiled
into
it,
and
it's
not
really
needed
by
offending
this
trial.
C
It's
only
needed
for,
let's
say
the
site
Thrift,
you
know
test
harness
and
for
some
reason,
the
way
the
sci
Thrift
server
code
was
structured.
It
expects
these
routines
to
be
in
the
vendor's
lib
side,
but
it
really
ought
to
just
be
compiled
in
the
in
the
PSI.
Let's
say:
PSI
Thrift
server
harness
and
not
required
to
be
in
the
vendor's
code
and
I,
just
kind
of
experimentally
found
out.
C
It
was
needed
in
in
the
dashlib
side
a
couple
years
ago,
so
it's
been
in
there
ever
since,
but
it's
it's
kind
of
a
let's
say
it's.
It's
unnecessary
burden
on
vendor,
PSI
and
so
The
Hope
was
to
move
that
that
code,
linking
and
compiling
into
the
sci
Thrift
server
itself
and
I
had
asked
for
others
to
look
into
that
who
were
responsible
or
familiar
with
the
side.
Thrift
server,
so
that's
kind
of
where
it
stands
and
Camille's
been
making
a
lot
of
nice
overhauls
to
the
side.
C
Thrift
server
he's
got
the
compilation
done
cut
in
half,
maybe
Camille.
Do
you
have
any
comments
to
make
on?
Let's
say
the
what
the
Horizon,
what
the
future
might
look
like
if
we
fix
this
problem,
do
you
see
for
this
to
be
improved
in
the
site?
Script?
Server?
Now
that
you've
looked
at
it
extensively.
D
D
Because,
right
now
in
the
in
the
Sonic,
we
are
developing
some
parts
of
the
orchids
and
that
will
be
communicating
with
the
thing
div
to
make
Dash
calls
and
based
on
that,
we
will
develop
some
unit
tests
on
on
top
of
that.
But
currently
the
way
the
occasion
is
built,
we
required
some
some
regular
site
apis
like,
for
example,
creating
like
host
interface
or
digital
router,
or
some
trap
groups.
D
D
C
Yeah,
okay,
so
that
was
a
lot
of
information
thanks.
Let
me
see
if
I
can
summarize
it,
it
really
would
be
helpful
to
have
the
the
PSI
metadata
object
code.
We
need
it,
we
need
it
in
the
real
Sonic
system
somewhere
and
it's
needed
in
the
side.
Thrift
server
overall
assemblage,
but
where,
where
that
code
gets
compiled,
the
link
is
sort
of
still
up
in
the
air
right
now
it's
compiled
into
lib
PSI
you're,
saying
it
could
be
compiled
into
its
own,
live
SCI
meta.
D
Yeah
so
so
I
already
prepared
like
another
PR
in
the
dash
report.
That
also
simplifies
the
like
completely
compilation
of
the
leap
site
that
is
still
an
open
PR
and
after
that,
on
top
of
that,
I
can
make
it
to
instead
of
compile
Phillips
I
metadata
into
the
leave
site,
I
can
like
to
make
it
to
be
like
separate
leave,
cymata
data
that
could
be
also
installed
next
to
the
leap
sign
and.
C
Yeah
so
you're
saying
that
could
be
a
follow-on
PR
once
once
this
PR
passes
through
yes,
yeah,
okay,
well,
that's
promising!
So
let
me
this
is
PR.
432
I
think
it
came
on
the
weekend
and
it
was
a
long
weekend.
I
kind
of
ignored
stuff
for
once,
I'll
take
I'll,
take
a
look
at
it
and
you
know
that
sounds
promising,
so
432
might
be
the
the
one
stepping
stone
and
then,
after
that,
you're
suggesting
you
could
optimize
it
one
more
step
and
make
a
lips
yeah.
So.
D
D
C
D
B
C
No
so
Andre
what
what
he
said
was
and
there's
a
lot
to
unpack
is
that
he'll
just
take
the
libsi
meta
and
make
a
separate.so
out
of
it.
We'll
still
build
it,
but
it's
not
required
to
be
in
the
lib
side
itself.
It'll
just
get
linked
into
the
final
output,
so
nothing
should
change
from
a
PTF
point
of
view.
Yeah
yeah,
the
final
sci-thrift
server
will
still
have
all
that
code
in
it
I'm
just
going
to
break
it
into
two
libraries
livesci
and
then
libsymeta
and
they'll
all
get
linked
together.
C
B
D
B
A
A
F
A
A
A
E
Correct
and
then
let's
say,
if
you
scroll
down
further
yes,
explanation
contains
like
let's
say
if
the
packet
is
just
trying
to
this
10108
from
that
will
be
the
original
packet
right
and
then
how
the
transformation
happens
from
this
one
to
the
V6
and
then
after
V6.
Then
there
will
be
another
layer
of
encapsulation
with
the
again
V4
using
the
V
pipei
right.
So
that's
the
that's.
How
the
transformation
and
the
from
the
original
packet
looks
like
yeah,
okay,.
E
A
F
G
I
think
the
the
question
is
more
about
like
the
packet
format,
instead
of
like
a
packet
pipeline
processing.
So
in
here
we
have
the
SDM
pipeline
basic
element.
Dock,
and
here
we
show
the
visuals,
like
probably
on
the
packet
action,
looks
like
if
we
scroll
down
a
little
bit
we'll
see
like
service
turnover.
So
this
one
is
for
private
link
and
this
one
is
for
foreign.
G
F
B
F
Saw
this
diagram
I
think
diagrams
were
not
made
specifically
for
dash.
They
were
made
for
like
the
existing
vfp,
yeah
and
so
I
I
know
from
I.
Think
some
of
the
other
examples
on
this
this
section
I
was
concerned.
It
may
not
be
exactly
what
happens
with
Dash,
so
I
didn't
want
to
make
that
assumption.
So
yeah.
E
F
G
Oh
I
I
see
so
I
think
when
we,
when
we
look
at
the
when
we
look
at
this
diagram,
what
you're
mentioning
is
actually
absolutely
correct.
So,
basically,
what
Dash
is
modeling
is
basically
from
the
from
the
VN.
Then
it
goes
into
the
VIP
section.
That
is
then
he's
mostly
like
what
that
she's
looking
at
so
then,
so
the
only
difference
between
this
graph
and
the
graph
or
you
should
how
we
look
at
the
graphics
and
the
The
Source
VM,
for
example.
G
G
So
step
one
we'll
have
the
original
packet
then
goes
to
step.
Let's
say
after
the
step
one
goes
into
the
VIP
section.
It
will
have
our
link
up
then,
after
the
entire
VIP
processing
like
on
step
five,
we
should
get
exactly
the
same
package
as
you
know,
the
diagram
shows
and
then
it
will
go
to
destination
destination.
Does
the
same
thing
goes
to
Max?
Max
is
not
in
the
dash
device
out
of
picture
out
of
the
well
Dash
modeling.
Yes
out
of
the
path
yes
and
then
you
go
to
the
max.
G
Does
whatever
you
need
to
do
needs
to
do
send
to
the
other
VM,
and
then
the
packet
comes
back
comes
back
to
Source.
Max
then
goes
to
actually
16
and
in
the
16.
This
is
when
where
we
will
receive
the
packet,
so
the
packet
will
have
two
layers
of
income.
If
I
remember
correctly,
what's
really
using
this
case,.
A
E
G
Yeah
yeah,
so
that
then
it
will
be,
the
packet
will
receive
and
then
it
will
go
through
the
you
know
the
dash
pipeline
again
in
and
in
the
return
password
we
should
be
doing
a
flow
match
because
the
inbound
and
then
to
transform
the
packet
back
to
the
step
20.
But
with
the
end
cap,
on
top
of
it,
foreign.
F
E
F
E
F
Okay,
so
so
normally,
when
we
get
a
packet
in
inbound
or
there's
an
outer
header
outer
tunnel
header,
we
pop
off
or
Decap,
and
then
we
do
the
flow
lookup
on
the
header.
That's
revealed,
which
in
this
case
would
be
the
red
header,
and
here
you're
saying
it's
not
going
to
be
the
red
header.
It's
going
to
be
the
orange
header
instead.
F
E
F
E
The
the
reason
why
I
didn't
put
that
was
because
the
inbound
is
happening
in
the
in
in
the
hardware
right
like
based
on
the
flow,
because
there's
no
exception
path
for
the
inbound.
If,
if
the
floor
doesn't
match
it's
a
it's,
a
draw,
yeah
so
I
mean
the
how
it
is
being
done
like
Chris
mentioned.
If
we
can,
we
can
give.
D
E
E
F
E
F
Okay,
so
again,
I
guess
like
just
in
general.
The
the
things
that
aren't
describe
clearly
enough
here
for
me
were
like
what
the
format
of
the
packet
is
coming
in,
like
what
what's
the
the
header
stack,
what
gets
decapped
from
that
packet
and
what
the
key
keys
are
for
the
flow
lookup
like
I
wasn't
sure
if
it
was
like
the
middle
stack,
the
ipv4
addresses,
or
the
innermost
header
stack
with
the
IPv6
addresses
and.
G
I
think
this
this
is
a
this
is
the
problem
here
is
and
because
Market
is
outside
of
the
dash
pipeline
and
then
actual
incaps
coming
from
the
box.
It's
not
coming
from
the
dash
paper,
so
the
dash
problem
is
not
available
to
create
a
flow
that
starts
the
double
income
and
also
in
the
inbound
path,
if
my
understanding
correct
a
contract
lookup
after
the
uni
lookup,
which
means
that
the
auto
in
tab
is
already
decapped
before
we
do,
the
you
know
the
the
floor.
Yeah.
G
Yeah
that
that's
why
we
need
to
think
about
like
how
to
deal
with
the
double
income,
because
we
need
to
make
sure
the
innermost
packet
is
exposed
before
we
do
the
flow
lookup
and
in
this
case
we'll
have
the
two
layers
of
income.
So
we
actually
need
to
pass
two
layers
to
actually
expose
in
the
most
high
cutout
to
actually
make
the
floor.
Look
then
it's
my
understanding,
I
think
that
is
what
bodies
of
mentioning
what
did
I
did
that
get
you
right.
F
G
Yes,
okay,
we
we
fall
for
the
forwarding
and
missing
for
the
river
okay,
yeah,
so
I
think
the
the
the
only
missing
piece
is
that
when
the
written
packet
comes
back,
we
probably
need
to
need
some
description.
Let's
say
how
to
handle
the
double
end
caps:
how
to
how
to
handle
double
income
before
we
doing
the
flow
lookup.
F
Yeah
I
mean
as
long
as
the
the
the
the
sort
of
the
logic
is
described,
I
mean
if
it's,
if
it's
a,
if
we
have
to
Decap
two
headers,
if
the,
if
the
logic
is
Decap,
one
header,
then
look
at
the
format
of
The,
Middle
or
I
should
say
the
next
header.
If
it's
GRE,
then
Decap
it
again,
I
mean
if
that,
if
that's
the
logic,
that's
fine,
I,
just
kind
of
need
to
know
what
it
is.
G
Oh
I
think
Prince
means
the
Frodo
cup
part
so
photocopy
is
based
on.
You
know
different
different
Hardware,
maybe
nothing
that
does
slightly
different
thing.
So
then
these
yeah
for
the
photo
cover,
we
will
just
say:
okay,
we're
doing
a
flow
lookup
that
is
but
before
the
photocopter
there
are
like
two
stages
over
there.
We
probably
need
to
describe
that.
A
A
F
A
H
A
H
E
D
H
Okay,
yeah
yeah,
so
this
one
right
yeah.
So
if
you
look
at
that
right,
there
are
actually
three
tables
in
this
diagram:
there's
a
meter
policy
table
at
top
and
then
on
the
right,
there's
meter,
class
mapping,
table
and
meter
bucket
table.
So
probably
the
meter
class
mapping
table
in
meter
bucket
table
can
be
logically
combined.
I
guess
and
then
you
can
say
it's
a
4K
buckets
per
eni,
so
so
that
part
I
think
is
okay.
It
is
a
table
up
there,
which
is
called
meter
policy
table
I'm.
E
H
H
A
C
A
A
I
E
Yeah
I
think
the
build
Ripper
is
still
working
on
that
the
it's
not
some
of
the
things
are
still
not
public
to
to
build
a
full
image.
I
think
it
is
a
it's
an
active
work
in
progress
and
we
can
we'll
be
soon
getting
there,
but
we
have
some
reports
like
swss.
We
have.
The
dash
code
is
public
and
unmerged.
E
A
D
So
there
is
this
difference
in
the
size
Runners,
because
the
BM
W2
doesn't
support
this
IP
list,
and
currently
there
is
like
the
difference
between
what's
in
the
five
headers,
which
is
generated
from
the
industry
and
that
is
actually
in
the
site
in
the
side
report.
So
it's
actually
someone
working
on
that
to
to
support
that
IP
list,
or
is
that
just
hanging
in
the
air
right
now.