►
From YouTube: SONiC DASH Workgroup Community Meeting July 12 2023
Description
Merged #393 into main - cleanup in dash testcases
The SAI header files in both OCP repo and DASH repo are not in sync (except for local changes that someone might be doing)
The Workaround in the meantime is to recompile w/DASH libsai to run for SAIThrift tests; when running w/full SONiC we have to use OCP SAI version, so Vijay has to run 2 versions
As the goal, we will want to use 1 Master branch
PR1813 now makes sure the test framework has the proper fixes. PR for the dash repo to update the refpoint to the latest OCP SAI.
fix in sai_api_gen.py.
Update SAI refpoint to OCP SAI by ravi861 · Pull Request #398 · sonic-net/DASH (github.com) (to dynamically derive # of ports)
Closed #346 - Volodymyr - Handled by #398
DASH SONiC SWSS move to Master - Prince
Need to discuss in SONiC Community (Yanzhao and Xin requesting to move)
The ask is to move the DASH HLD to the SONiC Repo, yet the DASH HLD for DPU will remain separate. We could place a pointer from the DASH Repo to the SONiC Repo.
PR400 Update
PR395: Chris ran small experiment, updated the Issue
Introduction/Welcome: Rao: NapaTech
A
B
Yeah
so,
as
we
know,
the
dash
PTF
involved
quite
a
bit
of
this
rainbow
changes
Etc
to
make
the
device
not
automatically
assume
32
ports
of
64
ports
as
a
switch
would,
but
instead
actually
dynamically
derived
the
number
of
ports
and
and
all
the
test
cases
for
cyan
delay.
Etc
were
were
ported
to
make
it
work
on
the
ipu
dpu
devices.
B
So
there
was
a
breakage
in
the
site
and
you
know
so.
We
couldn't
update
the
ocp
sci
ref
point
in
our
Dash
to
point
to
to
get
the
top
of
tree
site
code
as
a
sub
module,
where
our
Dash
PDF
changes
have
already
been
merged,
so
that
we
can
utilize
that
in
a
overlay
test
cases
and
dash
test
cases
and
CI
Etc.
B
B
A
D
D
D
A
D
A
A
C
I
got
a
general
question
about
what
pieces
are
missing
for
for
sunny,
build
with
Dash.
That's
one
thing,
and
the
second
thing
is
Sonic
with
four
dpus
will
be
I
believe
a
subset
right.
It's
not
the
full
thing.
It's
just
probably
the
side
radius
and
the
I'm
a
very
limit,
a
portion
of
the
the
overall
Sonic.
So
will
the
bill.
If
that's
correct?
Well,
the
will
there
be
information
somewhere.
Once
all
the
pieces
are
in
the
Sonic
to
to
build
the
dpu.
Only
Sonic
Image.
D
D
Yes,
yes,
I
I,
understand
the
point
yeah.
Today
it
is
like
a
Sonic
sir.
It
is
swss
and
build
image
and
we
are
also
trying
to
build
a
virtual
search
image.
So
I
think
the
instructions
are
missing,
but
we'll
we'll
try
to
update
it
for
TPU
in
the
Sonic
build
image.
So
already
there
are
instructions
for
some
platforms,
so
I
think.
Once
we
have
all
these
set,
we
can
update
the
the
build
instructions
in
Sonic,
build
image.
D
D
D
D
Yeah,
so
one
of
the
feedback
that
even
even
we
record
during
the
initial
discussion
of
Apple
tagging,
is
to
use
a
list
instead
of
a
bitmap,
so
I
think
now,
when
we
did
further
analysis
of
the
tag,
implementation
seems
like
link.
A
list
is
a
is
a
more
convenient
way,
so
I
just
change
the
requirements
from
bitmap
to
list
and
that's
one
one
change
and
the
other
one
is
on
the
metering
to
write
to
resolve
the
priority
across
policy,
routing
and
mapping.
D
Mapping
takes
precedence
over
routing
and
policy
irrespective
of
the
default
priority.
So,
like
line
number
141
says
about
a
default
priority
right,
which
is
first,
is
policy.
Then
it's
out
then
it's
mapping,
but
if
the
override
flag
is
set
in
the
mapping,
then
that
takes
priority
over
both
routing
and
policy,
because
earlier
I
was
not
mentioning
about
policy
in
this
statement.
So
there
was
a
confusion:
whether
override
flag
will
only
overwrite
routing
metering,
or
it
also
overrides
policy.
D
B
D
D
D
Yeah
yeah,
that's
right,
okay,
so
this
one
yeah,
please
feel
free
to
give
me
any
comments.
If
there
are
any
the
first
one
this.
The
second
is
that
third
in
the
list
right,
the
first
path,
design
requirements.
So
this
one
is
about
the
more
on
the
requirements
of
fast
path.
A
detailed
design
of
first
path
is
going
to
come
as
a
separate,
PR
or
document,
because
first
path
is
actually
a
is
a
major
scenario
and
we
already
have
a
document
on
fast
path
like
Krishna.
D
This
document,
yeah
I,
have
provided
a
link
to
this
document
in
in
my
PR.
So
that
way
the
scenario
is
explained
here
yeah
this
basically
like
you
know,
mixer
sending
an
icmp
redirect
message
so
that
the
vm1,
when
it
wants
to
communicate
to
back-end
Services
it
doesn't
have
to
go
through
a
public
or
a
Nissan
BMX.
Instead,
it
can
change
its
own
source
and
destination
IPS
too,
to
the
to
the
PA
address.
So
that
way,
the
the
communications
after
the
initial
ones
will
be
will
be
direct
right.
D
E
D
Is
yeah?
This
is
the
document
on
on
explaining
scenario
and
what
what
control
are
the
considerations
like
if
you
scroll
down
yeah
like
yeah,
it
has
the
explanation
of
how
it
works
and
those
things
maybe
scroll
down
a
bit
as
well
yeah,
and
then
we
have
yeah.
This
document
also
captures
the
packet
signature
right.
So
how
the
icmp
redirect
packet
looks
like
yeah,
I.
D
D
Yeah,
so
so,
basically
yeah
the
different
fields
in
the
icmp
packet
and
how
we
can
identify
the
flow
which
matches
to
that
fast
path.
Fast
path,
flow
by
looking
into
different
fields
of
the
redirect
packet,
but
like
I
mentioned
like
this,
is
at
a
high
level,
a
requirement,
but
there
will
be
more
details
coming
in
the
fast
path
design
document,
because
this
is
not
a
small
feature,
so
this
will
require,
like
apple
tagging.
D
D
As
a
feature,
yes,
there
will
be
more
discussion,
but
this
is
like
basically
at
a
requirement
level
what
what
we
need
to
achieve
by
by
the
icmp
redirect
and
and
so
once
we
have
the
agreement
on
on
the
packet
format
right.
The
detailed
design
can
consider
that
as
a
standard
okay
and
then
from
that
standard
of
attributes,
we
can
identify
the
the
fight
Apple
for
for
identifying
the
flow.
D
B
A
E
D
Okay,
yeah
so
basically
like
the
in
the
packet
payload,
contains
this
struct
format.
So
that's
why
I
just
put
it
like
that
and
after
that
I
also
explained
in
the
in
the
bottom
work.
What
are
these
fields
for
like
before
your
comment?
It
was
not
there.
So
if
you
scroll
down
a
bit
Christina
so
I
explained
this
truck
in
in
yeah
in
in
this
format,
mm-hmm.
E
Yeah,
just
to
the
as
a
alternative
thought,
I
mean
just
something
to
think
about
you
know:
P4
is
actually
appropriate
language
for
showing
header
Fields.
If
you
ever
want
to
use
that
instead
of
C,
because
it
actually
describes
packets
very
well,
but
that's
fine,
I'm
sure
he's
and
software
engineer
can
make
sense
of
this.
E
One
yeah
and
I
did
spend
a
little
bit
of
work
on
it.
I
if
you
scroll
down
to
the
bottom,
I've
got
a
long
post
there,
yeah,
so
I
went
and
Revisited
this
it's
been
quite
a
while
since
I've
worked
in
this
area-
and
they
asked
was
to
not
require
vendor
implementations
of
livesci
to
have
the
side
meta
compiled
into
it,
because
it's
only
needed
for
Sci
Thrift
server
for
test
harness.
E
E
Saying
hey,
I,
need
these
psymeta
object
modules,
they're,
missing,
I
can't
finish
the
final
link
and
if
those
only
needed
for
side
Thrift
server
I
would
think
they
need
to
be
compiled
in
the
site
server
stage,
not
the
lib
size
stage.
So
that's
my
my
working
hypothesis
and
someone
wants
to
take
that
next
step
and
try
that
or
it
can
take
a
stab
at
it
sometime.
B
E
And
I
I
found
empirically
that
I
needed
to
Link
Link,
the
sci
meta
objects
into
lib
PSI,
and
that's
why
I
came
up
with
this
make
file,
but
now
that
there's
many
participants,
they're
saying
hey
this,
this
really
shouldn't
be
part
of
the
production
website,
don't
make
it
be
required
to
live
there
and
then
the
only
place
it
can
live
then
is
in
the
sci
Thrift
server
build
it.
Could
it
could
compile
and
Link
those
parts?
I,
don't
think
this
is
a
big,
a
difficult
issue.
It
just
requires
some
probably
changes
to
the
side.