►
From YouTube: DASH Workgroup Community Meeting July 20 2022
Description
SAI PTF update
ACL group PR152
Keysight update(s)
DASH ACR
A
Dash
community
meeting
today,
I
put
the
agenda
on
the
screen
here
and
we
had
a
couple
of
different
things
to
talk
about
not
in
any
particular
order.
So
we
have,
you
know
a
sci
ptf
update
from
intel
and
mukesh
had
a
work
item.
He
wanted
to
talk
about
and
keysight
had
a
small
blurb.
They
wanted
to
talk
about
with
respect
to
the
pipe
ci
cd
testing
harness
and
pipeline,
and
then
I
wanted
to
point
out
something
later
about
the
the
runners
and
the
azure
container
registry.
B
Yeah
I'll
just
give
a
brief
introduction,
because
let's
spend
some
time
and
then
hand
it
off
to
both
anton
and
volodymyr
so
yeah
we,
the
there,
is
the
sci
ptf,
which
is
the
psi
packet
testing
framework
that
we
have
added
from
intel.
It
is
an
auto
generated
python
based
data,
plane,
testing
framework,
the
framework
itself
uses
thrift
wrapper
functions
to
call
c
based
sci
functions
in
python
scripts.
B
We
have
made
this
code
changes
at
this
time
for
the
auto
generation
framework
to
be
adapted
to
dash,
as
well
as
the
base
test
cases
and
anton
and
volodymyr
will
show
what
these
changes
are.
That
have
been
done
and
where
are
the
changes
in
the
framework
and
the
test
cases
itself
yeah
and
basically
show
the
community
how
we
can
use
these
changes
to
start
writing
more
test
cases
on
top
of
it
anton.
Would
you
like
to
please
take
over
yeah
sure.
C
Basically,
so
that's
a
site,
helper
class
and
here
is
actually
example
of
that
setup.
That
was
like
in
the
there
was
involved.
24
ports
with
a
different
pre-configuration
and
actually
each
test
case
was
used,
was
using
only
subset
of
those
tests
of
those
sports
like,
but
so
that's.
The
idea
was
that
we
did
configuration
once
and
then
launched
a
number
of
test
cases
on
that.
On
the
same
setup,
but
taking
only
those
parts
that
actually
required
for
that
test.
C
For
that
specific
scenario,
that's
a
good
approach,
but
with
testing
dash,
we
had
actually
the
the
problem
that
we
do
not
have
24
percent.
We
cannot
use
the
that
kind
of
approach
and
we
had
to
split
standard
24
percent
up
into
few
smaller
one,
mostly
for
two
ports.
What
we
expected
to
have
in
this
dash-
and
so
that
means
that,
instead
of
having
one
side
helper
class
in
the
ptf
player
framework,
we
will
have
multiple
preset
ups,
based
on
the
test
case.
C
Here's
actually
like
an
example
that
we
might
have
some
small
setup
with
two
reef
ports.
We
might
have
some
small
setup,
for
example,
with
log
if
we
need
it,
so
all
just
two
person
assigned
with
any
preset
up
in
the
future,
so
those
changes.
Actually
what
volatility
showed
on
the
demo
last
time
and
right
now
we
pushed
it
and
right
now
we
refined
that
those
changes
in
the
ptf
do
not
break
anything
for
existing
speech
scenarios.
C
C
What
I
want
to
like
stress
here
is
that,
instead
of
doing
like
child
classes
from
the
side
helper
as
it
was
for
all
test
cases
in
this
framework
before
right
now,
we
can
do
we
can
change
this
behavior
and
instead
of
using
that
standard,
24
port
setup
for
switch,
we
can
inherit
from
simplified
class
which
do
not
contain
that
big
press
setup
and
use
a
small
one.
What
we
need
actually
for
the
dash
use
case
and
yeah.
C
C
I
want
also
to
emphasize
that
we
do
not
rework
all
test
scenarios,
because
not
all
of
them
are
applicable
for
dash,
because
multiple
scenarios
actually
like
may
just
may
not
be
supported
by
dash
at
all.
We
right
now,
working
on
the
underlay
part
only
and
some
scenarios
might
require
more
than
two
ports
like,
for
example,
five,
seven
or
so,
and
we
also
do
not
touch
those
test
cases
and
keep
them
as
this
for
now
like
in
the
future,
we
will
do
so
like
our
so
once
we've
done
this
pushing
all
under
latest
cases.
C
C
Playbase
test
and
what's
new
there
is
that
say:
helper
base
is
completely
the
same
thing,
and
next
we
added
by
the
way
additional,
let's
say
helper
class.
This
is
say,
help
retails
mixing.
We
move
to
all
additional
methods
that
are
used
in
multiple
places.
In
the
test
framework,
it
will
be
used
for
as
a
also
one
of
the
apparent
classes
for
them,
say
helper
original,
say
helper
and
say
helper
simplified
one.
C
So
that's
just
common
methods
like
create
lag
members,
destroy
and
all
that
stuff
and
take
a
look
that
this
is
new
class
that
we
added
it's
inherits,
utils
and
say
helper
base
class
and
right
now
we
do
not
do
any
preset
up
here.
So
it's
actually
like
contains,
like
let's
say,
two
unassigned
ports.
What
additional
also
was
mentioned
by
voldemort
on
the
demo,
so
it
will
skip
test
cases
if
there
is
a
call
to
the
ports
that
is
not
actually
available
for
the
for
for
our
device.
C
Let's
say
because
those
support
lists
is
taken
from
the
cycle.
If
we
do
not
have
ports,
for
example,
with
that
number,
then
we
are
skipping
the
test
case
psi
helper,
like
we
using
mixing,
but
in
general
it's
it's
not
changed
at
all.
It's
only
like
different
standard
setup.
The
only
difference
is
that
we
like
using
that
helper
function
means
to
make
it
more
readable
and
easier
easier
to
read
and
the
most
simplified
way
like
let's
say
the
rest.
It
again
the
same.
So
now,
let's
look
to
the
sum
test,
cyrif.
C
C
C
It's
also.
I
think
it's
good
amendment
to
the
existing
coverage.
So
just
to
summarize
so
right
now
style
reef
is
already
pushed.
You
can
try
it.
You
can
see
how
how
to
use
psy
simplified
class.
How
to
do
that
preset
up!
You
can
take
a
look.
What's
has
been
changed
in
the
psi
based
test
and
as
a
next
steps.
Next
few
days
we
will
finish
pushing
our
few
other
test
seats
so
yeah
and
want
to
remind
that
we
do
not
convert
all
test
cases.
C
A
B
C
B
D
D
D
D
Yes,
so
we
we
can
probably
merge
this.
So
let
me
show
you
file
yeah,
so
there
is
a
pdf
user
guide,
so
there
is
instruction
what
you
need
to
to
have
it
to
be
able
to
install
it
and
also
how
to
install
dependencies.
We
we're
going
to
update
this
guide
one
once
it
is
merged
with
the
swift
version
that
is
supported
for
the
sun
sonic
and
also
there
is
instruction
how
to
generate
it,
how
to
run
on
the
server
side,
because
swift,
actually
swift
ptf,
is
run
on
the
client.
D
We
call
it
as
a
client
and
the
street
server
is
running
on
the
dude,
so
we
cautilize
the
server.
So
there
is
example
how
to
run
on
the
device
under
test
so-called
server
and
also
the
instruction
how
what
you
need
and
how
to
run
on
the
test
controller,
to
be
able
to
send
any
traffic
and
run
the
test
cases,
and
there
is
an
example
comment
how
how
to
run
it
so
should
be
pretty
straightforward.
Maybe
there
is
some,
you
know
issues
so
please
let
us
know
what
I
would
like
to
add.
D
Probably
so
we
already
published
those
changes
and
you
can
run
it.
So
the
question
is
in
scope
of
the
dash
where
you
can
run
it
okay
right
now,
so
maybe
it's
it
makes
sense
to
try
on
the
bmv2.
I'm
not
sure
what
are
the
supported
list
of
the
features
that
bm
v2
can
support
and
if
you
can
run
it,
but
maybe
it
it,
it
did
a
good
starting
point
starting
point.
Yes,
where
you
can
run
it
yeah.
I
don't.
E
I
don't
this
is
chris
thanks
for
the
presentation
and
all
the
work,
I
don't
think
there's
any
underlay
features
in
the
bmv
too.
So
right
now
this
is
sort
of
waiting
for
you
know,
let's
say
a
hardware
implementation
to
try
it
on.
If
someone
has
or
a
software
simulation,
you
know
that
a
vendor
might
have,
but
I
don't
think
they're.
You
know
the
bmv2
isn't
going
to
support
these
tests
at
this
moment.
I
don't
know
if
there's
really
any
plans
to
add
underlay
features
to
bmv2
model,
there's
nothing
stopping.
But
it's
effort
right.
E
Yeah,
this
will
be
real
good
for
well,
we
can.
We
can
start
adding
overlay
tests
and
we'll
talk
about
that
shortly,
but
I
think
if
vendors
are
porting
sonic
to
their
actual
platform
in
the
process
of
that,
then
this
would
be
a
great.
You
know
way
to
start
testing
for
the
basics
right
without
even
worrying
about
stateful
services,
just
to
make
sure
that
the
sonic
stacks
working
that
you
know
everything
is
as
it
should
be.
B
E
A
A
A
B
F
A
A
F
Basically,
it's
like
so
today
we
just
have
one
flat
tackle
table,
whereas
what
gma
has
is
like
apple
group
and
then
that's.
The
group
id
is
driven
from
the
eni
for
each
of
the
stages
and
then
within
that
aqua
group
there
are
a
bunch
of
rules
for
each
active
group,
so
try
to
model
it
that
way
in
p4
and
generate
psi
apis.
F
G
F
G
F
Yeah,
so
please
yeah,
if
you're,
okay,
with
that,
we
can
actually
merge
that
take
a
look
and
approve
that
one
as
well
and
then
one
other
question
I
had
from
md
me
and
vijay.
We
both
had
this
question
about
how
to
address
these,
for
the
echo
group
right
how
to
address
the
priority
within
the
group
priority
of
each
rule
that
is
knotted
here.
So
maybe
that's
another
thing.
We
need
to
discuss.
A
E
E
E
And
then
it'd
be
nice
to
merge
that
into
main
this
is
to
fix
the
permission
issues.
It's
not
the
elegant
long-term
solution,
but
it
seems
to
work
well
enough
for
now
long
term.
I
have
to
make
sure
the
container
user,
ids
and
everything
are
sorted
out.
That's
a
bigger
project
with
a
lot
more
regression
testing,
but
this
fix
just
does
the
change
change
mode,
sha
mods
on
all
the
file
directories
and
people
have
tried
it
out.
E
E
The
bigger
one
I
want
to
do
soon
is
this
one
and
I'd
like
to
get
that
merged
in
because
it's
a
pretty
big
change
in
terms
of
splitting
up
all
the
containers,
and
I
want
to
get
that
into
everyone's
workflow
sooner
rather
than
later.
I
think
it's
ready
to
go,
and
I
know
at
least
when
several
people
tried
it
out.
So
there's
no
objections.
E
You
know
I'd
like
to
merge,
merge
that
you
know
maybe
later
today.
So
if
anyone
wants
to
try
it
out
one
more
time
you
need
to
go
in
and
you
know
pull
pull
this
branch.
You
know
get
my
repel
and
check
out
this
branch
and
follow
the
instructions
pretty
comfortable
that
it's
working
well,
I
do
want
to
get
that
in
because
it
will
have
an
impact
on
all
the
other
merges
and
and
whatnot
that
are
pending.
E
One
thing
we
didn't
have
until
now
is
an
actual
scithrift
server,
that's
working
in
the
dash
repo
for
the
behavioral
model,
and
also
one
that
links
with
the
sci
library
that
we're
generating
so
I'd
like
to
share
that
I've
got
this
working
as
of
last
night.
Finally,
and
so
it
builds
this
entire
scithrift
server
infrastructure
and
pulse
code
from
the
psi
repo
and
build
scripts.
So
this
is
actually
depending
on
the
work
that
intel
did
last
fall
this
auto
generation
and
trying
to
report
it
to
dash.
E
I
found
a
few
very
small,
easy
to
fix
issues
that
are
pending
and
pull
requests
and
other
than
me
learning
a
lot
of
things
for
the
first
time
it
went
pretty
well,
so
we
can
now
build
all
these
containers
that
are
in
these
shaded
boxes
and
run
the
entire
process,
and
I
actually
have
a
mini
demo,
but
I'll
stop
in
case
there's
any
questions
just
about
the
overview
here.
What
it
all
means
any
questions.
E
E
E
So
this
switch
right
now
is
listening.
Listening
on
this
socket
for
p4
runtime
table
access
commands
nothing's
being
done
yet,
though,
now
I'm
going
to
run
the
scithrift
server
and
in
the
diagram,
that's
this
okay,
so
this
is
going
to
run,
and
that
includes
the
libside
which
was
auto-generated
from
the
p4
code,
and
we
talked
about
that.
E
Maybe
a
month
or
two
ago,
marion
demonstrated
that
so
just
as
a
refresher,
the
p4
code
gets
compiled,
creates
p4
info
that
gets
turned
into
psi
headers
and
that
gets
bound
into
libside
and
that
code
also
is
generated
and
what
it
does
it
takes
psi
api
calls
like
table
and
attribute
commands
and
translates
them
into
the
equivalent
p4
runtime
remote
procedure
calls
over
the
socket.
So
we
have
this
server
running
it's
listening
here.
That's
waiting
to
be
told
something
so
what's
going
to
tell
us
something,
is
this
everyone
follow
so
far?
E
Okay
feel
free
to
hold
up
your
hand,
so
I'm
going
to
run
that
server
and
not
much
is
happening
yet
this
starting
psi,
rpc
server
on
port
9092,
but
believe
me
to
get
to
this
point-
was
a
couple
weeks
learning.
So
now
we've
got
this
and
it's
listening
on
this
socket
1992
is
listed
on
port
1992
for
site
thrift
commands
now.
E
E
E
Now
this
I'm
doing
a
tcp
dump
on
the
thrift
port
and
on
the
p4
runtime
port.
So
when
I
run
make
all
tests,
it's
going
to
do
a
bunch
of
activity
on
everything.
Okay,
so
it's
initialized
people
run
time.
It
sent
a
bunch
of
packets.
Okay
just
ran
a
whole
bunch
of
tests
and
all
I'll
go
through
these
a
little
bit.
E
E
Is
this
v-net
out
test
that
marion
wrote
many
weeks
ago
and
all
does-
is
a
single?
Maybe
a
couple
of
table
accesses
through
psi.
I'm
gonna
point
to
this
diagram.
Again,
it's
a
it's
a
hand,
coded
c
plus
plus
program
that
makes
a
psi
access
and
it's
not
really
using
side
threat,
but
it
verifies
that
the
cythrip
I
mean
the
side
to
be
for
runtime
works.
So
that's
the
test.
That's
still
in
there.
E
Okay,
this
is
the
c
plus
plus
code
that
was
kind
of
the
starting
point
and
I
won't
walk
through
it
all,
but
it's
just
doing
some
basic
sci
apis.
You
know
just
like
you'd
see
it
in
you
know
the
let's
say:
syncd
daemon
or
something
it's
it's
low
level
psi
accesses.
So
that
works
still
another
thing
it
did
before
it
did
anything
it
had
to
configure
the
p4
switch
with
its
p4
program
and
that's
a
p4
runtime
command
called
set
forwarding
pipeline
config.
E
So
what
that's
doing
is
actually
downloading
a
json
file
to
bmv2,
which
is
going
to
then
interpret
interpret
to
run
the
dash
pipeline
and
I'll
I'll
try
to
document
this.
So
you
know
you
don't
have
to
depend
on
remembering
this
meeting
or
watching
the
video
I'll
write
it
more
about
it.
When
I
get
time,
but
that's
how
the
switch
gets
initialized
and
you
can
see
that
this
is
this-
is
the
p4
runtime.
E
E
E
So
here's
set
forwarding
pipeline
config.
It's
downloading
all
this
json!
You
can
see
it's
it's
an
http
2
and
it's
a
set
request
and
it's
got
all
this
json.
So
that's
just
a
little
bit
of
inner
workings
for
people
who
want
to
get
into
the
low
level
and
then
I'll
show
see.
Let
me
show
you
stuff
on
the
thrift
part.
E
E
E
E
E
So
this
is
client
code
and
it's
telling
it
here's
the
client
that
was
obtained
and
it's
obtained
behind
the
scenes
in
a
setup,
setup
script:
it's
setting
the
data,
the
the
direction
lookup
entry
is
telling
it
set
outbound
direction.
Okay,
so
that's
it!
This
is.
This
is
actually
all
it
takes
to
program
a
table
and
it's
magically
going
through
this
whole
step.
E
That's
in
python,
so
let
me
ask
the
crowd
which,
how
would
you
like
to
write
your
tests?
Oh
and
this
same
code
should
work
in
a
ptf
test.
Now
I
will
need
to
do
some
testing
to
find
out
what
you
know
how
good
the
translation
is.
Can
these
commands
be
used
exactly
in
the
ptf
test,
because
if
they
can,
I
would
propose
that
we
take
setup
code
and
put
in
a
common
place
that
either
test
framework
can
invoke,
and
that's
that'll,
be
an
ongoing.
E
You
know
work
in
progress
to
find
out
how
we
do
that
in
the
most
effective
way.
But
if
we're
doing
things
like
setting
up
tables
and
setting
up
configurations,
we
don't
need
to
write
the
code
twice.
The
overall
framework
that
surrounds
all
this
will
be
a
little
bit
different
and
that's
still
one
thing
should
really
change
from
framework
to
framework.
Both
frameworks
have
their
advantages
that
we've
talked
about,
so
I
think
they're
both
beneficial
to
have
in
parallel.
D
Just
maybe
answer
your
question
so
yeah,
so
the
code
will
looks
pretty
much
some
and
I
would
say
even
the
same
as
you
wrote
for
the
pi
test.
It
will
be
absolutely
the
same
for
the
ptf,
so
there
will
not
be
any
change,
but
you
know
there
will
be
difference
between
how
you
send
and
receive
traffic
and
how
you
use
the
physical
ports
that
that's
only
one
difference
probably
will
be,
but
the
configuration
itself
will
looks
pretty
the
same
because
you
are
trying
to
use
the
size,
rift
library
and
in
the
pta
ptf.
E
Right
so
there's
gonna
be
a
lot
of
harmony
here
and
what
I
haven't
done
here
is
actually
sent
traffic,
yet
I
didn't
get
that
far
but
there'll
be
commands
here
to
you,
know,
configure
packets
and
send
them
and
and
then
look
at
the
captured
packets
back
and
make
some
assertions
about
their
contents.
So
that's
work
to
be
going
forward,
but
the
big
thing
is
this
framework
actually
works.
E
Yes,
it's
very
nice
and
I'll
point
out
one
more
time.
This
repo
pulls
in
the
sci
repo
as
a
git
sub
module,
and
it's
tracked
by
commit
sha
right.
So
we
always
know
what
we're
getting
from
psi
and
anytime.
We
want
to
get
an
updated
version
of
side.
We
just
change
the
the
reference
in
the
dash
repo
and
it
will
then
pull
in
that
version
of
size.
So
it's
not
going
to
be
uncontrolled
where
it
just
gets
latest
it'll
be
specific,
so
we
can
proceed
in
a
very
orderly.
E
You
know
configuration
management
style
right
now,
because
I
have
a
few
pull
requests
against
psy
to
address
some
small
issues.
I
found
I'm
actually
pulling
a
git
fork
from
my
own
repo
that
has
the
prs
already
incorporated
once
those
get
merged
into
psi.
Then
I'll
switch
this
over
to
pull
from
the
side
rebuild,
that's
how
you
can
always
be
in
some
known,
orderly
state.
You
can
work
on
dev
branches
and
this
and
then
go
back
to
the
mainline
repo.
You
can
go
back
and
forth
like
that.
E
E
So
right
now
this
is
in
a
dev
branch
and
I
want
to
play
with
it
another
week
at
least
I'd
like
to
get
this.
The
scythe
rip,
the
docker
diet,
one
merged
in
first,
which
is
about
halfway
to
this
point
and
then
and
then
do
some
more
work
on
this
branch
get
some
feedback
from
early
adopters
who
want
to
pull
this
fork
and
try
to
build
it
to
make
sure,
there's
no
surprises,
and
then
hopefully
we
can
merge.
E
This
then
we'll
actually
have
a
starting
point
to
start
writing
tests
and
one
thing:
that's
nice:
this
is
my
visual
vs
code
workspace,
but
when
this
is
all
pulled
and
the
sub
module
is
expanded,
you've
actually
got.
This
is
the
side
directory
in
dash.
It's
not.
The
sai
repo
under
here
is
the
get
sub
module
of
psy,
so
anyone
who's
been
in
the
sai
repo
to
recognize
all
these
directories.
E
You've
actually
got
a
full
snapshot
of
the
sci
repo,
including
ptf,
test
cases
right
in
this
workspace.
So
it's
actually
very
convenient
to
be
able
to
work
work
in
this
mode,
because
you've
got
everything
you
need.
You
don't
have
to
bounce
around
and
you
know
people
are
not
real
familiar
comfortable
with
with
sub
modules.
We
can.
We
can
talk
about
it
more
or
you
can
read
up
on.
You
know,
github.
E
There's
references
be
happy
to
show
people
some
of
the
some
of
the
nuances
of
working
with
sub
modules,
so
hopefully,
in
the
next
couple
weeks,
we'll
be
ready
to
have
people
start
contributing
tests
mari,
and
I
would
like
to
have
some
help
in
defining
a
meaningful
v-net
test.
I
mean
intel
wants
to
help
too.
So
we
get
some
kind
of
a
configuration
and
some
packets
in
versus
packets
out
guidance.
We
now
have
a
framework
to
write
them.
E
E
E
Got
it
so,
I
think
the
code
and
everything
here
is
is
in
such
a
shape
that
we
could
come
up
with
a
task
list
and
people
could
volunteer
for
things
like
all
right.
I'm
gonna,
I'm
gonna
change
the
auto
generation
code
to
add,
set
or
or
what
was
it
set
and
wasn't
removed,
set
command
in
the
read
command
and
you
know
that's
something.
E
E
And
get
yeah
we
need
to
set
and
get
so
you
could
come
in
and
what
this
is
doing.
It's
it's
actually
doing
some
p4
runtime
stuff.
Okay,
so
you
have
to
kind
of
figure
this
out,
but
it's
a
fun.
It's
a
fun
thing
to
look
at,
so
anyone
could
volunteer
for
that
work
if
they
are
so
inclined
marion.
If
you
had
to
do
it,
when
do
you
think
you
would
get
to
sit
and
get.
G
E
E
A
E
A
A
Yeah
yeah
I'm
trying
to
find
the
screen
where
I
had
it,
but
chris
and
I
and
prince
collaborated
to
go
ahead
and
create
the
container
registry.
I
just
kind
of
wanted
to
show
everyone,
but
oh
I
found
it
okay,
so
just
fyi!
This
is
prince.
Thank
you
for
the
pointer
by
the
way,
so
we
were
able
to
get
this
created
so
that
we
can
use
it
moving
into
the
future
for
testing
and
images,
and
things
like
that.
So.
E
A
D
E
E
D
E
Yeah,
but
we
have
all
the
existing
ptf
tests,
don't
really
apply
because
they're
all
kind
of
under
light,
so
they'd
be
new
testing
overlay
and
so
based
on
what
we
talked
about
earlier
I'll.
Try
we'll
try
to
write
it
in
a
way
where
we
can
reuse.
The
configuration
part
come
to
either
test
and
we
should
try
both,
I
like
to
like
to
try
and
experiment,
to
see
how
things
go
before
we
do.