►
From YouTube: SONiC DASH Workgroup Community Meeting Feb 15 2023
Description
○ Inbound_routing scale#233
- All scale questions answered in first half
- Might want to break this issue into 2 and close first half to close and open for second half (Anton volunteered to create another made sure to @ in the thread)
○ Confirm # of routes per ENI?
○ Adding scale requirements in the tables in the repo
○ PR #332
- P4 DPDK target, added instructions on how to build and run
Consider starting a dev to get back end running for dash. He would be happy to integrate into the workflow
A
Awesome
awesome
so
good
morning,
good
evening
my
name
is
Yousef.
This
is
the
Sonic
Dash
work
group,
community
meeting
call
and
today's
date
is
February
15th
and
we're
going
to
go
ahead
and
pick
up
where
we
left
off.
It
seems
that
we
were
leaving
off
on
kind
of
stopping
the
metering
discussion
and
going
to
move
forward
with
the
action
item
of
just
waiting
to
discuss
into
the
P4
pipeline
was
kind
of
implement
it
there.
A
A
A
So
for
the
PRS
there
was
actually
one
PR
that
I
made
note
of
a
while
back,
and
there
was
just
not
opportunity
because
of
the
floral
conversation
to
kind
of
bring
that
up.
There
was
a
PR
mentioned
for
the
inbound
routing
scale
that
has
been
open
for
a
little
while
and
then
there
was
not
any
added
comments
there.
A
B
B
Extracting
this
error
information
out
and
then
we
can,
you
know
kind
of
close
the
original
original
case,
because
some
people
like
butter,
are
sort
of,
let's
say
stuck
with
this
issue
in
their
in
their
on
their
radar.
Even
though
it's
not
their
issue
yep,
so
I
guess
I
would
ask
Anton.
Do
you
want
to
work
together?
Somehow
move
this
into
its
own.
C
Yeah
I
was
going
to
be
a
volunteer
because,
like
that's,
why
my
comment
about
the
real
box?
Let's
look
forward.
I
will
open
a
new
one
and
then
I
will,
if
I
have
a
permission.
I
will
close
this
or
just
put
a
comment
that
we
can
close
this
one
because
a
new
one
is
opened
and
I.
We
will
have
at
least
the
number
here
for
Drake.
B
D
D
F
A
F
D
G
F
All
right,
that's
what
I
assumed
also
right
so
yeah
yeah.
That's
why
I
and
I
never
actually
saw
anywhere
mentioning
of
a
separate
PA
validation
table,
at
least
not
in
any
of
the
dark
at
all,
even
in
the
in
in
the
P4
P4
code.
So
if
that
were
to
be
the
case,
maybe
you
know
we
can
table
that
thing.
Maybe
we
can
Define
it
later,
but
at
least
you
know
something
that
something.
F
D
G
G
A
D
A
E
Gonna
start
to
start
talking
about
the
scale.
I
think
that
we
have
some
kind
of
table
in
the
scale
requirements
document
in
the
dash
repo.
So
maybe
we
can
put
the
whole
information
there
in
the
one
table
and
we
can
provide
even
more
scary
points
for
different
tables
that
will
be
kept.
You
know
in
one
place
like
c2pp,
invent
routing,
government,
routing
and
all
I
know
that
some
are
already
there,
but,
for
example,
like
ipv684
would
be
great
to
have
there
also.
E
D
D
D
B
D
B
D
Another
so
I
wanted
to
mention
that
we
also
have
the
P4
dpdk
Target
today
as
part
of
P4
line.
This
has
the
driver
software,
that's
needed.
The
software
stack
that's
needed
for
the
paper
dpdk
Target
and
down
here.
There
is
a
readme
that
shows
how
to
build
and
install
the
P4
in
the
before
duplicate
Target.
So
and-
and
it
also
has
an
example
here-
so
example
of
LPM-
you
know-
and
how
to
use
the
LPM
to
basically
verify
that's
just
an
example.
D
So
at
the
moment,
if
we
can
take
the
P4,
the
P4
that
Andy
has
compiled
and
used
those
artifacts
and
Supply
those
artifacts
here
to
this
driver
software
for
the
p40pdk
Target,
we
can
actually
run
that
before
and
to
be
able
to
test
it.
We
can
launch
the
BF
shell,
that's
also
part
of
this
software,
and
then
we
can.
D
You
know
test
one
particular
table
at
a
time
like
the
LPM
example.
That's
shown
down
here
so
I
just
wanted
to
show
that
to
everyone
here
and
we
need
some
help.
Actually,
we
are
trying
to
find
folks
with
an
Intel
to
run
this
P4.
We
might
be
able
to
do
that,
but
if
anyone
wants
to
collaborate
in
this
effort,
please
let
me
know
as
well.
B
G
G
Okay,
so
this
is
optimizing,
the
dash
axle
the
effort
is
to
to
make
sure
we
are.
We
are
optimizing,
the
memory
and
those
Footprints.
So
so,
basically,
the
the
idea
is
like.
If
you
look
at
the
dash
axle,
the
source
address
is
like
a
list
of
prefixes
right.
So
that's
how
we
have
defined
it
in
in
previously.
G
But
what
happens
is
like
for
each
rule
in
the
Apple
table?
You
can
have
the
same
set
of
prefixes
that
are
repeated
across
the
rules
right
so
so
like,
for
example,
if
there
are
like
a
thousand
prefixes
in
this
Source
address
field
like
it,
it
is
possible
that
the
same
set
of
thousand
prefixes
are
repeated
for
another
roll
number
as
well.
G
G
E
G
It
not
right;
no,
it
can
either
way
right
because
sometimes
the
stuff
prefixes
can
be
like
just
one
or
two
IPS
right.
So
in
that
case
you
don't
need
to
create
attack
for
every
single
thing,
but
this
is
intended
for
cases
where
you
have
like
hundreds
of
thousands
of
prefixes
in
in
in
in
which
is
like
repeatedly
used
right.
So
we
keep
the
flexibility
of
using
the
source
address
and
the
as
the
as
the
actual
list
of
prefixes
as
well.
F
Okay,
how
do
you
define
because,
at
least
in
the
definition,
no
sorry?
Basically
this
is
the
definition
you
know.
Somebody
would
basically
create
an
instance
of
this
and
then
says:
okay
I
want
to
really
Define
it
and
I'll
specify
this
thing,
but,
but
in
in
this
particular
case,
how
do
we
designate
that
you
know
if
one
is
defined?
The
other
one
is
not
necessary
right.
E
G
G
F
G
G
E
D
E
D
H
C
Prince
I
also
have
a
question
regarding
so
I
saw
that
in
the
Sonic
management
you
have
merged
we
net
this
case,
and
my
question
is
whether
you
have
at
least
what
else
should
be
actually
executed
on
the
dash
in
scope
of
the
Sonic
management.
So
that's
I,
like
personally
expect
bgp
any
cell.
Anything
else
like.
Are
you
going
to
have
some
changes
in
the
test
cases?
G
Oh
yeah,
okay,
yeah
sonic
management.
We
have
added
the
v-net
to
v-net
test
right,
so
yeah
there
will
be
there's
already
some
of
the
the
underly
just
like
bgp.
We
can
reuse
from
Sonic
management.
It
is
I.
Think
team
has
already
run
those
tests
and
and
found
to
be
passing
for
bgps
and
bgp
facts
those
tests,
but
on
top
of
the
current
one,
we'll
be
adding
like
more
of
actual
test.
Based
on
this
new
change,
LED
acne
test
and
some
IPv6
based
scenarios
as
well.
G
C
Thank
you
yeah.
So
that's
like
it's
not
for
high
school,
like
we
see
in
big
big
Labs
with
many
multiple
devices,
but
just
as
a
quick
start,
we
can
make
even
a
PR
to
Sonic
mentioned
it,
because
it's
luck
only
of
one
script
and
it
will
be
possible.
If
anybody
is
interested
in
this,
we
can
do
this.
Pr.
F
Hey
Prince
I
have
a
quick
question.
I
know
you
need
to
go
in
like
four
minutes
or
so
I
was
going
through
the
documentation
like
the
Sonic
Dash
hld,
one
thing:
since
we
have
the
topic
of
ACL,
it
mentions
about
like
three
levels
of
Asia
like
V,
init,
subnet
and
v-neck
right.
So
what
was
it
the
case
that
the
v-net
is
especially
v-net
is?
Is
v-native,
ACL
is
defined
by
say,
Azure
and,
and
the
the
rest
too,
like
unique
and
subnet
are
from
the
customer.
Is
that
right.
G
F
One
thing:
yeah
one
thing
that
I
I
want
to
really
you
know
just
get
some
clarification
on.
My
part
is
perhaps
maybe
I
don't
know.
You
can
point
me
which
document
it
is
if
there
are
any
examples
of
different
these
kind
of
stages
like
what
is
what
is
really
considered
as
a
subnet
ACL
versus
winning
versus
v-net,
and
also
does
it
matter
in
which
order
they
get.
You
know
evaluated
because
eventually,
the
the
restrictive,
the
most
restrictive
the
result
is
entertained
right.
But
yes,.
F
G
I
think
order
doesn't
matter
right.
It
goes
through
the
stage
one
and
then
to
stage
two
like
so
we
have
defined
in
the
pipeline.
So
so
and
then,
like
you
said
it's
the
most
restrictive
that
wins
right,
but
what
examples
for
each
stages
I
think
I
can
I
can
discuss
with
Christian
and
provide
some
some
data
on
that.
G
G
A
Okay,
so
we
got
a
couple
really
great
questions
to
kind
of
circle.
Circle
back
to
I
was
able
to
kind
of
take
note
on
that.
Just
making
sure
that
we
understand
about
the
bulk
API
and
see
if
there's
any
documentation
around
that
and
I
know.
Sunny
and
Christina
are
going
to
connect
to
be
able
to
give
a
little
bit
more
clarity,
just
around
the
difference
between
the
subnet
Echo
and
the
vena
Echo
yeah.
So
I
was
able
to
kind
of
take
note
on
that.
A
A
It
was
more
so
this
is
a
conversation
before
on
just
understanding
the
difference
between
the
v-net
apple
and
the
subnet
apple
and
stuff
like
that.
But
we
already
kind
of
reviewed
like,
for
example,
332
reviewed,
the
the
other
PR
that
Richmond
was
able
to
bring
up,
but
just
trying
to
make
sure
that
we
kind
of
touch
on
everything
that
we
wanted
to.