►
From YouTube: DASH Test Workgroup Community Meeting 20211201
Description
December 1, 2021 Community Call
B
B
B
It
can
cover
some
simulation
use
cases
as
well,
so
it
can.
It
can
work
for
you
as
a
reference
for
designing
the
psi
for
for
the
dpu
for
the
vendor's
dpu
device
and
so
on.
So
this
one
has
a
definition
of
all
of
the
packet
transformation,
so
it
is
based
on
the
p4v1
model,
so
for
those
that
are
not
familiar,
p4
language
has
different
target
architectures,
like
any
other
instruction
set.
B
All
of
the
code
is
based
in
the
ingress
control
block
and
all
of
the
transforms
are
done
there.
Also,
besides,
that,
we
have
some
stuff
defined.
That
is
not
part
of
the
official
before
language
like
if
you
look
into
the
connection
tracking,
so
this
part
is
under
a
special
defined
because
it
won't
compile
if
you
would
just
take
the
regular
open
source
p4
p4c
front
end,
so
this
one
describes
stateful
operations
done
on
the
packet,
in
particular
connection
tracking.
B
B
B
So
these
also
are
kind
of
work
in
progress.
They
are
not
supported
for
the
simulation,
but
instead,
when
we
are
when
we
do
the
simulation-
which
I
can
also
show
you
later,
they
are
substituted
for
now
with
the
regular
match
kinds
supported
by
p4,
which
is
exact
and
range,
but
in
the
future
we
want
to
also
expand
software
simulation
to
support
those
lists
as
well
as
connection
tracking.
So
this
is
kind
of
the
dvd
section.
B
Everything
else
that
you
can
find
in
this
directory
is
basically
supported
and
can
be
compiled
and
run
on
the
software
switch.
So
this
is
one
part
that
we
have
in
dash.
Second,
one
is
psi,
so
this
one
is
the
interesting
part
about
psy
is
that
we
have
this
overlay
api,
which
describes
all
of
the
dash
related
packet
transforms,
and
this
one
is
generate
generated
from
the
compiled
p4
application.
B
So
I
can,
I
can
explain
you
the
process
as
well,
so
the
tools
are
not
part
of
this
repository,
but
if
you
want
them
available,
we
can
add
them
to
dash
as
well.
So
now,
let's
go
to
to
my
repository,
it's
got
all
the
tools,
so
you've
got
a
similar
thing
in
here.
If
you
look
at
the
bmv2,
it's
basically
the
same
key
for
implementation.
Nothing
different!
B
Next!
If
you
look
into
sci,
you've
got
the
tools
that
allow
you
to
generate
say
api,
so
underlay
apis
are
basically
just
for
the
reference
they
are
taken
from
the
standard
site.
So
it's
not
nothing
special
about
them,
whoever
overlay
apis
they
are
compiled
from
from
the
result
of
p4
compilation.
So
let
me
see
if
I
have
probably
I
don't
have
an
example
right
now,.
B
I
think
it's
like
a
free-form
conversation,
so
documentation
on
the
list
and
range
list
kinds.
No,
we
don't
have
the
documentation,
but
yeah
yeah
you're
right.
So
this
is
this
is
what
was
defined
for
the
acl.
This
means
that
if
one
in
the
list
matches-
and
it
means
that
the
field
matches
basically
that's
the.
B
E
So
you
said
that
the
apis
are
generated
based
on
the
p4
program,
they're,
auto
generated
right
and
one
of
the
questions,
one
of
the
things
which
we
were
trying
to
understand.
I
was
talking
to
gohan
earlier
that
the
current
overlay
definitions
they
are.
They
are
what
we
call
as
a
functional
api,
meaning
that
they're
higher
level
abstractions
right.
B
B
C
B
B
B
Because
that
would
require
us
to
integrate
p4
runtime
into
sonic,
and
then
you
will
have
a
split
brain
situation
when,
where
you
have
part
of
the
application
working
on
top
of
psy
part
of
the
application
working
on
top
of
p4
runtime,
and
then
you
would
have
to
make
them
work
together.
I
believe
like
having
one
set
of
apis
is
easier
for
application.
G
H
Marian
on
the
p4
side,
you
know
this
p4
program
that
you
mentioned
about
the
serious
pipeline.
This
one
is
just
the
reference
you
know,
p4
behavior
model
to
generate
the
the
psi
api.
This
is.
This
is
not
something
that
you
know
that
we
are
really
talking
about
running
it
in
a
in
a
target
hardware
right.
H
So
right
now
right
so
so
in
in
that
sense,
you
know
the
objective
was
to
generate
the
psi
api
and
if,
if
the
psi
apis
are
going
to
be
any
other
psi
api
that
we
are
used
to
in
say
in
the
underly
scenario
right,
so
how
is
it
really
different?
It's
just
if
the
objective
is
to
generate
the
psi
api
through
some
model
and
and
then
you
know,
have
the
same
model
as
we
have
today
in
sonic,
which
is
the
functional
apis,
whether
you
are
doing
underlay
or
overlay
and
underneath
it
the
vendor.
H
You
know
the
hardware,
vendors
or
asic
vendors
are
essentially
implementing
their
psi
adapters
right
to
really
map
to
their
sdk
or
whatever.
Have
you
right
so
yeah?
The
model
is,
you
know,
is
not
really,
you
know
p4
and
p4
runtime.
So
to
speak,
it
is
just
you
know.
The
three
four
right
now
is
just
the
means
to
an
end,
which
is,
you
know,
means
to
really
generating
this
high
api
and
nothing
else.
H
I
Compile
it
and
use
it
for
testing
you
just
you,
you
shouldn't
think
of
it
as
an
implementation,
though,
but
it
can
be
used
as
the
as
the
as
the
behavioral
model
that
everybody
needs
to,
regardless
of
how
they
implement
it.
Underneath
the
covers
needs
to
follow
like
you
can't
an
api
by
itself
doesn't
mean
much.
You
have
to
have
a
behavioral
model.
K
K
I
H
I
But
also
the
goal
is
to
make
it
make
sure
that
the
test
group
is
writing
automated
tests
against
this
behavioral
model,
and
then
they
don't
care.
What
kind
of
the
covers?
They
really
don't
care
which
asic
which
technology
they
use,
but
from
this
model
they
can
build
their
test
cases
sure
and
they
should
exactly
yeah
absolutely.
I
I
F
I
I
am
okay
with
all
what
has
been
said,
but
I
want
to
standardize
one
thing
my
concern
is:
I
don't
want
to
standardize
both
the
behavioral
model
and
the
api,
because
there
will
always
be
inconsistency
between
the
two.
So
if
we
decide
that
we
go
down
the
route
of
standardizing
the
behavioral
model,
then
the
tool
need
to
become
integral
part
of
the
standard,
and
we
basically
say
that
the
standards,
the
behavioral
model,
the
api,
is
generated
automatically.
I
E
E
They
still
have
abstraction,
which
is
at
the
table
level
right
and
if
you
have
a
higher
level
functional
api
which
operates
at
multiple
table.
I
don't
know
how
that's
done
and
that's
one
of
the
questions
I
had
and
concerns
as
well.
Do
we
do
we
have
any
melanox
people
here
who
wrote
the
first
male
actually.
A
E
B
E
B
E
B
E
E
B
Stitch
standard
stitching,
stitching
was
done
on
the
was
always
done
on
the
sonic
side
like,
for
example,
you
have
tunnel
and
you
have
tunnel
d-cup
entry.
Those
two
were
programmed
as
a
result
of
a
single
entry
in
sonic.
So
what
we
have
in
behavioral
model
today
for
sonic
usually
is
usually
per
table
entities,
and
then
they
can
be
programmed
in
a
batch
by
sonic
it.
B
B
E
Okay,
you
know,
I
think,
I'm
mary
and
I
got
it
so
so
what
you?
Let
me
just
my
question
was
more
on
the
data
plane
than
on
the
sonic
side.
So
what
we
are
saying
that
in
the
overlay
behavioral
model
we
specify
a
block
or
a
table,
that
table
is
a
logical
table
and
may
map
onto
one
or
more
tables
in
the
hardware.
Okay,
oh.
E
E
B
L
B
I
B
L
Yeah,
so
I
have
a
question
just
before
you
move
on.
You
show
me
that
snippet
of
code,
where
you
identify
the
match
kind
mine,
is
my
understanding
someone's
phone.
My
understanding
is,
you
can
only
identify,
you
can
only
specify
new
match
kinds
in
in
the
model
file
or
the
architecture
file.
So
are
you
going
to
define
a
new
architecture
other
than
v1?
Is
that
the
long-term
goal.
L
Yeah,
but
that
might
just
be
a
happy
accident,
so
that's
just
one
thing
to
to
put
on
the
side
and
figure
out
how
to
reconcile.
You
know
we
have
andy
here.
Who
can
he
can
grop
that,
and
maybe
he
has
some
comments
or
something,
but
we
probably
ought
to
reconcile
that
and
then,
if
you
have
other
constructs
like
in
the
connection
tracking,
you
know
those
look
like
fundamental
language
editions,
correct.
B
Kind
of
the
poc
stage
support
in
the
behavioral
model,
which
is
not
compiled
from
p4
but,
as
you
know,
the
behavioral
model
or
the
software
switch.
It
uses
the
json
output
of
the
compilation
to
use
as
a
pipeline,
and
you
can
basically
inject
definition
of
this
construct
in
the
json
format
into
the
into
the
pipeline.
B
So
it
will
actually
our
version
will
will
be
able
to
do
learning
itself,
but
this
is,
as
I
said,
this
is
only
the
poc
stage
and
we
at
this
point
I
don't
know
how
we
are
going
to
contribute
that.
So
this
is
something
like
an
open
question
right
now,
but
all
this
file
is,
it's
totally
like
alien
to
2p4
language.
L
B
I
can
yeah
I
can
describe
so.
Basically,
we
would
like
to
have
the
following
things.
We
would
like
to
have
all
the
p4
as
part
of
the
dash
and
and
also
the
tools
to
generate
the
apis
right
now
we
contributed
the
apis
themselves,
but
if
the
community
agrees
that
we
will
have
an
open
source
tool
and
then
we
don't
need
to
revisit
the
apis
just
rely
on
the
tool
itself
to
generate
them.
B
B
H
In
order
to
do
that,
you
know
I
mean
you
know,
these
are
definitely
great
goals
and
then
we
you
know.
I
completely
agree
that
we
should
do
that.
You
know.
Clearly.
One
thing
is
that
from
the
api
perspective
or
from
the
p4
behavior
model
perspective,
you
know
this.
Is
this
may
change
right
I
mean
you
know
we
may
find
something
that
okay,
we
we
need
to
really
enhance
that,
and
for
that,
if
the
tools
are
open
source,
then
we
can
easily
generate
the
the
the
updated
api
so
to
speak
right.
B
H
So
in
every
case,
what
I
see
this
thing
that
we
need
to
have
our
tools,
tool
chains,
which
are
you
know
in
one
case,
about
generating
auto
generating
the
apis.
But
the
second
thing
is
about
you
know,
generating
the
the
behavior
model,
and
then
you
know
the
code
for
the
software
switch
so
that
we
can
test
it
which
is
not
going
to
be
used
by.
We
cannot
use
the
open
source
current
tools
right.
H
L
L
You
know
at
least
the
the
big
things
like
language
changes
or
simulator
and
lisa
will
know
what
the
gaps
are
and
the
milestones
along
the
way
you
know
like,
like
I
tried
to
do
the
idealized
workflow
for
the
scithrift,
it
kind
of
identified
gaps,
and
maybe
we
need
you
know
some
to
drill
down
a
little
bit
at
some
point
figure
out.
What
are
what
are
all
the
steps
along
the
way,
the
major
steps,
and
is
there
a
concrete
plan
to
to
close
those?
Or
is
it
just
a
you
know,
ivory
tower.
I
You
need
to
stagger
this
a
little
bit
too,
because
the
ambition
to
be
able
to
just
generate
a
software
model
of
it
is
great,
but
in
the
meantime
there
are
people
with
asics
that
can
develop
and
want
to
test
even
before.
Maybe
even
before
that
occurs
right,
it
doesn't
have
to
be
all
or
nothing
it
can
be
like.
Well,
we
need
a
tool
to
generate
the
api
first
and
then
people
can
work
with
that
and
then,
if
we
can
simultaneously
develop
a
tool
to
generate
the
code.
Fine,
but
if
we
can't
work
doesn't
stop.
L
F
F
L
L
J
Yes,
after
marian
is,
you
know,
finished
with
some
of
this
presentation.
Maybe
chris
you
can
show
that
diagram.
Basically,
that
also
shows
the
tool.
The
sciptf
test
framework
that
intel
is
also
contributing,
given
the
psy
version
basically
generates
the
psi
apis
that
are
there
and
then
users
can
write
tests
to
use
that
framework,
and
you
know
there's
some
conversations
around
that
part
and
then,
as
gerald
was
saying,
everything
can
be
staggered.
J
You
know
as
much
as
possible
and
then
we
also
are
aware
of
the
pna
consortium
that
is
also
handling
the
smartening
side
of
the
world.
You
know
all
the
use
cases
there
and
addressing
that
in
the
p4
language
itself.
So
so
that's
something
that's
going
on
in
parallel
and
at
some
point
we
definitely
would
like
to
see
we're
sort
of
working
on
building
a
software
switch
that
can
use
a
pna
architecture
p4
program.
You
know-
and
that's
something
also
that's
going
on
in
parallel
with
an
intel.
B
G
G
B
K
I
I
had
a
question
about
how
it's
being
expressed
here,
I
mean
to
me
it
seems
like
it's
not
correct
like
it
looks
like,
for
example,
the
connection
is
removed
on
the
fin,
but
aren't
there
packets
continue
in
the
flow
all
the
way
through
that
you
know
the
acts
that
follow
the
fin
and
so
like.
I
like,
I'm,
not
even
sure
the
logic
that
you're
showing
in
this
you
know
stateful
connection
tracking
is
is
correct.
I
I
It's
it's
got
a
lot
of
good
work,
but
it's
a
giraffe
and
in
fact
I
know,
there's
excite.
I
know
there's
pensando
and
others
who
have
said
there's
things
wrong.
So
that's
okay!
Well,
that
should
be
fixed,
but
this
is
a
draft.
The
only
way
to
get
something
done
is
you
have
to
be
brave
enough
to
put
something
out
there
right.
So
melanox
put
this
out
there
and
what
we
should
do
is
take
any
input
from
anywhere
on
what's
missing
and
then
that
can
be
integrated
and
can
be
made
final.
I
K
I
E
I
Yeah,
christina,
you
could
actually
break
this
a
little
bit
up
the
behavior
model
itself
shouldn't
be
done
in
the
test
group
to
be.
I
agree
it
should
be
done
in
a
different
group.
It
could
be
the
same
people
go
to
that
meeting,
but
yeah
if
they
want
to.
But
it's
the
test
group
should
be
focused
on
testing
and
then
another
group
should
be
focused
on
getting
the
behavioral,
because
there's
seven
of
these
services
and
there'll
be
more
over
time
right.
A
Yeah,
but
you
guys
you,
you
guys,
have
to
understand
that
these
questions
stemmed
from
the
test
work
group
where
we
were
trying
to
trying
to
notate
the
testing
workflow
and
then
the
questions
around
p4
came
up
and
that
needed
to
be
understood
in
the
testing
group,
which
kind
of
fostered
this
meeting.
So.
But
we
can
certainly
do
that.
I
E
A
I
I
You
know
to
automate
the
testing
in
a
in
a
very
like
complete
way,
so
we
did
start
with
this
test
group
to
make
sure
that
it
starts
now
and
not
later
after
everybody's
like
finished,
defining
what
they
want
to
do,
and
then
they
test
becomes
an
after
effect.
It
has
to
be
something
you
start
with.
So
we'll
have
that
other
group
there
is
another
group.
E
N
I
I
Proprietary
implementation,
it's
because
it's
from
a
vendor
and
they're
not
going
to
disclose
their
implementation.
So
it's
you
know
it's
modeled
off
of
our
documents
that
we
described.
I
mean
everything
is
modeled
after
that,
but
the
actual
implementation
from
another
vendor
is
not.
You
know,
they're,
not
disclosing.
That.
I
I
F
E
O
And
yeah
gerald:
can
you
confirm
that?
Because
one
thing
we
agreed
is
that
we
will
use
p4
as
a
reference
model
as
a
single
source
of
truth
to
describe
the
behavior
right?
So
that's
that
and
then
other
implementation
we
want
to
go
in
parallel.
We
don't
want
to
wait
for
it.
We
have
psi
dot
h
as
a
reference
to
keep
working,
but
then
can
we
con?
You
confirm
that
connection
tracking
or
stateful
p4,
which
is
not
yet
standardized
you
know
in
quotes
yet
is
required.
I
Yeah,
it
is
required,
because
you
know
the
community
decided
that
p4
was
the
way
they
wanted
to
go
like
actually
to
me
it
doesn't
matter,
but
the
community
decided
to
go
that
way,
and
so
that
dictates
that,
yes,
we
have
to
deal
with
connection
tracking,
because
this
whole
project
is
a
connection
oriented
project.
It's
layer,
four
right,
so
that
to
answer
your
question,
yes,
we
need
to
do
that.
Work.
O
Yeah,
because
the
reason
I'm
asking
is
there
are
two
changes
here
that
are,
I
mean
two
thing,
two
things
that
are
different
than
the
standard
p4
one
is
on
the
on
the
match.
Kind,
but
match
kind
looks
like
is
a
syntactic
sugar.
What
it
means
is
that
I
could
translate
that
into
regular
p4,
hopefully
by
enumerating
port
numbers
from
port
ranges,
whereas
connection
tracking,
I
can't
do
that,
so
I
cannot
produce
a
a
agreed
community
agreed
standard
p4.
I
cannot
produce
that
from
this
stateful
implementation
and
there'll
be
multiple
implementations.
I
I
mean
we
have
to
make
progress
and
as
long
as
we're
going
to
go
down
this
road
of
p4
behavior
models
and
we'll
call
them
people
plus
now,
then
that
means
that
we
will
be
responsible
for
making
and
offering
the
code
to
make
that
happen
as
a
community.
However,
that's
gonna
occur,
otherwise
we
need
to
take
a
different
approach,
but
I
think
this
is
the
approach.
People
have
agreed
upon.
L
I
Well,
one
thing
I
want
people
to
understand,
though:
the
difference
between
this
and
all
other
standards
is.
These
are
the
use
cases
that
actually
get
deployed
nobody's
ever
published
it
ever
and
so
people
go
and
they
develop
apis
to
make
the
most
general
cases
work
that
are
unknown,
they're,
unknown
cases
they're.
Just
like
okay
build
this
api,
and
now
you
can
do
anything
and
that's
why
no
one
else
has
ever
been
able
to
get
the
performance
that
we
have.
I
I
I
have
no
problem
with
that,
but
don't
go
and
go
in
with
your
eyes
open
that
we're
not
looking
at
building
anything,
that's
less
than
millions
of
connections
per
second,
and
that's
not
tens
of
millions
of
connections
being
tracked
right.
That's
the
whole
purpose.
What
we
found
is
in
the
past,
because
we
did
the
same
thing.
We
built
a
software
implementation
and
software
hardware
combination.
Implementation
was
super
super
generalized
and
hence
super
slow,
and
we
want
to
avoid
that.
I
That's
why
we
published
these
seven
services
to
show
people
that
you
know
you
don't
need
to
go
up
and
build
that
kind.
You
know
this
general
approach.
If
you
build
this,
you
get
a
full
suite
of
services
and
you
achieve,
finally,
the
millions
of
connections
per
second
that
we
were
looking
for
effectively.
We
make
connections
invisible
to
the
applications.
So
keep
that
in
mind
when
you
talk
about
reuse,
we
are
not.
I
You
know.
Our
purpose
is
to
publish
and
reduce
this
flexibility
down
to
what's
needed,
not
to
leave.
People
wondering
you
know,
is
my
implementation,
something
you
can
use
and,
and
they
never
know
in
fact,
we've
never
been
able
to
adopt
technologies
under
that
circumstance
because
they
go.
I
don't
know,
maybe
yeah
gerald.
L
I,
like
you,
I,
like
your,
I,
like
your
commentary.
My
takeaway
from
this
conversation
is
the
standards
and
the
architecture.
Working
groups
need
to
sort
of
reflect
on
a
this
real
world
commercially
driven
implementation
and
a
adapt,
not
necessarily
the
other
way
around
that.
Maybe
maybe
there
needs
to
be
a
convergence.
It
would
be
nice
to
have
one
way
of
doing
things,
but
maybe
the
language
and
the
p
a
architecture
need
to
be
taking
this
into
account
and
maybe
morph
a
little
bit.
L
I
I
can
actually
come
out
with
something
that
I
can
offer
the
marketplace
and
then
it
can
be
modified
from
from
there
today.
New
technologies
are
not
adopted,
because
it's
too
hard
it's
it.
I
mean.
What
are
you
going
to
do
with
it?
It's
just
doesn't
fit.
There's
too
much
work
to
do.
Are
they
you
know
you
have
to
standardize
on
that.
One
supplier
work
with
that
supplier
for
years,
trying
to
get
it
right
or
you
do
what
we're
doing
here
and
you
say
like
no
we're
demons
to
find
this.
I
I
I
have
this
sonic
moss
and
even
if
they
had
a
second
one,
they
had
one
that
a
lot
of
people
could
look
at
and
judge
their
switch
by
tested
know
that
they
had
the
proper
behaviors
and
in
our
case
we
just
deployed
them
right
so
and
and
and
others
do
now
as
well.
We
want
the
same
thing
for
this
market.
We
want
to
be
able
to
deploy
multiple
technologies.
H
Yeah
so
quick
question
on
on
your.
You
know
description
as
you
mentioned
generally,
you
know
you
initially
you're
targeting
like
seven
services,
as
you
mentioned
right,
so
do
we
have
you
know
I
haven't
really
looked
at
in
detail,
but
all
these
behavior
model
that
we
have
in
the
serious
pipeline
do
we
is,
is
that
I
mean
all
these
behavior
model?
Are
they
really
tackling
all
the
seven
services
currently
or
or
do
we
still
have
more
work
to
to
do
there.
I
Well,
we
only
start
with
the
bean
at
the
other.
Six
in
english
form
they're
all
described,
but
not
in
not
in
this
programmable
form.
So
only
v-net
exists
in
in
this
form
and
we
will
define
the
other
six
once
we
get
this
one
done,
because
we
have
to
start
somewhere
because
we
need
to
test
it
out.
Remember
test
is
number
one.
We
need
to
actually
start.
The
group
start.
The
test
group
start
this
make
sure
everybody
agrees
on
how
to
approach
this
and
how
to
auto
generate
things,
blah
blah
blah.
I
I
A
Okay,
so
we
have
about
well
we're
actually
over.
We
have
if
anyone
can
go
further,
that'd
be
great,
so
should
we
let
marion
continue
or
should
we
switch
over
to
the
testing
slide
that
we
had
presented
last
time
and
let
reshma
have
have
a
minute
marion?
Was
there
a
lot
more
to
say
on
this
part
of
the
presentation.
B
I
believe
not,
I
think,
like
for
the
next
meeting
or
two.
I
can
work
on
what
you
mentioned,
like
this
description
of
the
flow,
how
it
should
all
come
together,
how
you
compile
it,
how
you
generate
site
api
out
of
that,
so
I
I
think
everyone's
got
an
idea.
Next
steps
will
be
more
concrete.
What
gaps
we
have,
how
to
use
it,
and
so
on.
I
L
B
A
L
Okay,
can
I
get
is
my
screen
showing
yeah
so
so
marion's
discussion
was
kind
of
involved
in
this
area
here
this
p4
2
header
files
and
and
and
simulator
workflow
and
reshma.
I
think,
wanted
to
talk
a
little
bit
about
this.
Sci
thrift
generator
and
this
powerpoint
and
and
pdf
are,
are
in
the
repo.
So
people
are
welcome
to
take
this
and-
and
you
know,
use
it
to
build
on
if
they
want
to
make
pretty
pictures.
J
Thank
you,
chris
for
being
bringing
this
powerpoint
up.
So
last
time
we
had
discussed
about
using
sci
ptf
framework
that
intel
is
adding
to
be
able
to
generate
the
psi
apis
and
then
you
know,
as
we
have
streamed
some
of
the
test
cases,
we
can
enhance
that
to
make
it
to
extend
it
to
smartening
side
of
things
and
also
had
ex
extended
test
cases
using
that
framework.
J
J
Building
and
testing
a
switch,
and
not
really
smart.
Nick
by
that,
what
I
mean
is
the
number
of
ports.
Those
expectations
are
different,
and
today
it
is
geared
towards
testing
with
the
sonic
management
test
framework
that
is
already
there.
So
there
will
be
some
changes
that
are
required
in
the
test
framework.
The
the
test
framework
itself
is
being
upstreamed
at
this
time.
J
I
think
that
activity
will
be
completed
by
january,
but
if
we
were
to
extend
that
to
for
it
to
be
usable
in
the
smartnic
side,
then
then
there
are
some
changes
needed
and
we
are
okay
to
take
up
some
of
those
activities,
work
that
is
needed
to
do
that,
but
again,
starting
january
again,
we'll
be
working
with
gohan
and
team
to
be
able
to
achieve
that
yeah.
That's
pretty
much!
All
I
had
thank
you.
Restaurant.
L
To
clarify
that
would
be
take
kind
of
getting
this
part
of
the
workflow
into
the
test
code.
Generator
right
now.
You
just
take
this,
and
what
we
want
to
do
is
somehow
work
this
in
and
then
build
test
cases
and
parameterize.
This
whole
thing
so
that
it
can
accommodate
different
platforms
right
different
targets.
J
N
D
Yeah,
no
just
I've
been
a
data
plane
wonk
for
years
at
cisco
and
so
now
at
intel
and
co-chairing
the
there's,
a
there's
several
p4
working
groups.
The
architecture
working
group
is
the
one
I'm
a
co-chair
of,
but
I'm
also
active
in
the
language
design,
work
group
and
you
know,
program
working
and
working
on
defino
and
p4
rival,
nixon
intel.
D
I
think,
as
and
when
like
new
match
kinds-
or
you
know,
other
things
are
proposed-
that
we
think
if
people
think
they
ought
to
become
part
of
the
language
standard,
then
that
would
be
appropriate.
Then
some
of
these
things
might
be
that
the
language
language
group
tends
to
be
fairly
conservative
on
additions.
I'm
not
saying
it's
impossible,
but
you
know
there's.
I
D
A
A
I
I
Yeah,
I
think
it's
more
than
a
it's
a
discussion,
so
I
think
we
need
that
meeting
to
get
this.
This
behavioral
model
done
and
finalized
it's.
It
won't
get
finalized
unless
there's
more
communications
with
people
like
that
are
on
this
call
a
lot
of
input
that
that's
much
faster
than
just
putting
I
mean
I
don't
mind
using
the
dash
type
for
questions,
answers
and
that,
but.