►
From YouTube: SONiC DASH Workgroup Community Meeting Apr 5 2023
Description
PR350 - Add protobuf description for dash app_db (NorthBound)
Targeting app_db and Orch Agent, but no changes to SAI
Previously used strings and characters, moving to protobuf for efficiency
Chris: might be helpful to have a diagram. Taking individual key values and turning it into a binary blob.
Prince: asic_db will be on different DPUs, app_db stays on host machine. Don't see a reason to store these things on asic_db (as you would in a switch).
Marian: data type? Encoding key and value - will there be a different data type used for protobuf?
Ze (Pterosaur):
Chris: is this for 1 DPU or for 1 switch? App_db, asic_db, REDis, sizes, etc…what is stored where, how big, etc…? Into SONiC.
Guohan: this # will be divided between the DPUs
Chris: If we have a DASH Orch and can apply a large scale config to a db, then we could determine the GB for a config. Memory footprint of a full DASH config in REDis?
Guohan: memory footprint is different than the format. If not internal data is in the sheet, perhaps @ze could publish? asic_db is still under investigation
A
Looks
like
one
new
person
here,
petrasar
and
so
a
proterosaur,
don't
know
how
to
say
it
exactly,
but
I
wanted
to
show
you.
These
are
the
meeting
notes
that
go
out
every
week,
see
and
so
I'll
make
sure
that
you
get
a
copy
of
these,
but
this
goes
out
weekly
and
it
talks
about
what
we
did
and
who
was
here
and
what
we
talked
about,
the
PRS
that
we
covered
and
the
updates
and
things
like
that.
A
So
I
just
want
to
let
you
know
that's
kind
of
what
we
do
so
based
on
last
week.
It
looks
like
we
had
a
I
mean.
We
all
know
the
things
we
covered
last
week.
It
was
pretty
heavy
heavy
week.
We
merged
a
lot
of
PR's
and
Marianne
helped
answer
this
question
here
and
we
we
did.
We
covered
the
issue
about
the
extravian
eyes
and
baby
hero
tests
using
TCP
all
that
stuff,
and
then
this
week
we
were
asked
if
we
could
add
PR
350
into
the
conversation,
so
I'll
pull
that
up.
A
A
A
B
Let
me
get
started,
let's
get
started
so
look
first,
let
me
introduce
some
background.
First
here
is
a
tip.
The
first
slide
I
will
introduce
the
typical
Sonic
table
in
the
typical
sewing
table.
We
use
radius
to
solve
each
entry
and
the
key
corresponds
of
table
name
entry
name
and
also
to
some
management.
Maybe
we
have
some
engine
name.
If
we
have
and
the
value
will
be
a
attribute
table
and
the
attribute
name
is
a
fixed,
constant
string
and
the
attribute
value
is
the
clear
text
for
each
tab.
B
If
IP,
it
is
something,
ET
will
appear,
integer
string.
So
here
is
the
example
to
veneer
table.
The
lower
left
picture
is
the
format
in
red
is
DB,
and
the
lower
right
table
shows
the
memory
consumptions
of
this
kind
of
format.
As
you
can
see,
the
total
estimated
memory
usage
is
about
65
gigabytes
is
of
each
number
is
based
on
the
scalability
table.
We
in
the
dash
high
level
design
talk.
B
B
Okay
and
right
now,
let
me
say
the
advice,
the
product
buffer
table,
lucky
it's
same
as
the
typical
design
and
the
battery
value
we
can.
We
only
have
has
one
pair
of
attributes
in
the
attribute
table,
so
so,
for
example
like
this
one,
obviously
too
many
same
attribute
name
has
been
removed
and
the
type
of
value
like
IP
will
be
compressed
to
the
binary
format.
So
we
play
the
directly
readabilities,
but
again
the
last
resource
consumption.
B
As
you
can
see
to
the
product
table,
we
will
only
take
about
40
gigabytes
to
the
also
to
the
loss
of
relatability,
but
I
believe
it
is
easy
to
return
by
Advanced
CLI.
If
you
want
to
read
something
from
the
release
table,
so
the
next
is
we
can
now.
We
have
a
three
advantages.
If
we
convert
to
the
product
path,
format,
the
first,
the
first
and
most
important
is
less
memory
consumption.
B
Is
a
bi-direction
compatibility,
which
means
in
the
code
level,
the
new
message
can
be
used
in
by
the
older
program
and
the
New
Field
will
be
ignore
the
end
you
know
program
can
also
read
a
lot
old
messages
where
some
new
field
will
use
the
default
value
and
it
will
will
also
will
get
a
clear
code
in
the
right
right
now.
In
low
occasions,
we
have
too
many
conversion
code
to
convert
the
string
to
the
Target
app
so
in
a
typical
design.
B
We
have
to
do
too
many
conversion
from
that,
and
right
now
is
the
last
slide
I
just
to
tell
us
how
to
tell
you
how
to
convert
a
table
from
schema
to
the
Target
profile
message
and,
for
example,
here
is
the
the
universe
path.
We
will
have
some
predefined
tab
like
IP
and
IP
prefix
range
and
or
something
and
then
I
I
have
a
table
of
map
about
how
to
convert
the
detailed
tab,
for
example,
to
the
building
in
a
program
and
to
a
list.
B
C
D
C
First
of
all,
I
think
in
the
community
here
for
development
at
least
public.
Don't
really
have
access
to
anything
radius,
but
that's
one
thing
at
least
Dash
related
radius,
but
from
a
PSI
API
standpoint
are
there
any
changes,
impact
I'm
trying
to
figure
out
how
this
fits
into
the
vendor
development,
I?
Suppose.
B
E
G
I
think
it
might
be
helped
to
have
a
diagram
of
this.
Just
it's
not.
Everyone
knows
the
Sonic
architecture
thoroughly.
I
want
to
make
a
couple
comments.
One
is
what
we're
doing
I
think
is
taking
individual
key
values
and
turning
them
into
a
binary
blob,
which
means
you
know
it's
like
all,
as
they
chunked
together
right
for
efficiency.
But
that
means
you
can't
really
address
through
redis
an
individual
item.
It's
a
blob.
G
Anyone
who
knows
about
the
current
state
of
the
art
and
dpus
can
look
at
this
and
say
this
exceeds
the
memory
on
a
typical
dpu
card
or
a
darn
large
portion
of
it,
which
means
this
is
potentially,
you
know
untenable
even
at
this
level,
but
I
think
we
need
to
understand
what
what
is
the
size
of
the
Asic
DB
for
these
configurations,
because
this
is
only
the
tip
of
the
iceberg
right
when
this
gets
turned
into
Asic
DB
entries
and
they
exist
simultaneously
in
redis.
What
do
we
have
then?
B
B
This
is
the
one
question
the
FDB
is
only
in
the
host,
so
in
the
host
the
DPO
will
use
the
SLS
because
we
can,
we
can
say
it
is
belong
to
another
machine
and
either
asset
can
also
access
the
host
machines
from
the
TTP
or
some
protocol,
but
to
the
86
DP
executive
will
be
in
the
DPO
and
basically
maybe
we
will
remove
it.
We
don't
need
it.
C
F
E
Right
I
think
the
point
is
in
in
different
architectures
right.
Let's
say
you
have
a
switch
architecture
where
there
is
a
single,
app
DB
and
then
distributed
actp,
then
it
can.
The
basic
DB
will
will
be
on
different
dpus
right.
So
so
that
way
the
the
usage
or
the
memory
consumption
is
distributed,
whereas
app
DB,
it
stays
in
the
host
machine
right.
C
C
G
G
Yes,
yeah
I
mean
there's
nothing
I'm,
not
at
all
challenging
this
optimization.
It
seems
like
a
good
proposal
to
start
with,
but
if
we
don't
step
back
and
look
at
the
implications
of
the
whole
system,
we're
going
to
get
to
the
next
problem
and
go,
how
do
we
get
here
right?
We
need
to
look
at
you
know
the
proposition.
E
G
F
E
Yeah
I
think
I
think
for
the
SCTV
part
we
have.
We
can
always
think
of
like
not
even
right
to
the
satp
right
to
just
push
the
config
and
then
don't
write
it.
So
it's
a
it's
part
of
the
sync,
the
implementation
on
whether
to
write
basic
debut
or
not,
because
we
don't
for
us.
We
don't
see
a
reason
why
we
need
to
save
all
these
things
in
actp,
unlike
the
switch
so
but
app
DB.
We
want
to
store.
H
E
H
E
E
I
E
H
E
J
J
J
Yeah,
the
the
representing
the
data
in
the
Asic
DB
on
the
dpus
at
the
scales
would
be.
It
would
be
a
challenge,
so
it
is
a
function
of
the
dpu
vendors
softwares
to
essentially,
you
know,
provide
appropriate
debug
capability
of
of
the
you
know
entries
in
in
their
you
know,
memory
tables,
I,
would
say
right
as
opposed
to
you
know,
keeping
everything
in
in
a
version
of
an
Asic
DB
at
the
scales
we
are
talking
about.
H
H
J
In
my
opinion,
that's
that's
hard
to
achieve
right
because
nobody
will
agree
on
on
what
that
standardized
mechanisms
are
going
to
look
like
as
long
as
the
app
DB,
config,
DB
stuff
is
represented,
and
you
can,
you
know,
figure
out,
what's
being
pushed
in
right.
You
have
a
layer
there
you
can
at
least
you
know,
Peak
and
poke,
perhaps,
and
and
then
beyond
that
it's
it's
somewhat
kind
of
specific
to
the
implementations.
H
Yeah
I
mean,
maybe
you
know
a
Microsoft
or
customers
really
can
be
a
judge
of
it.
You
know
there
is
a
vendor
side
of
you
and
then
there
is
a
customer
side
of
you
or
somebody
who
wants
to
debug.
You
know
the
actp
kind
of
functionality
across
different
vendors.
Are
they
comfortable
to
run
with
vendor
specific
debuggability
aspect
or
not
so
I'll?
C
B
B
C
F
E
That
depends
on
the
platform
architecture
right,
but
today
we
have
developed
the
code
for
dpus
and
and
based
on
today's
discussion,
it's
mainly
on
the
on
the
appdb
to
our
cage
inside
the
changes.
So
the
southbound
side
there
is
there's
no
change,
so
it's
pretty
much
stays
the
same
and
I
am
not
expecting
like
when
the
specific
changes
based
on
this
yeah
from
from
the
current
implementation.
F
E
F
Because
the
multi-asic
architecture
for
switch
right-
that
is
a
little
bit
different
from
how
we
CCP
dpus
here
right
dpus
have
their
own
compute
complex.
This
is
a
full
SOC,
so
it
has
much
more
capabilities.
So
we,
you
know
there
is
a
chance
to
run
whatever
we
need
a
control
plane
in
the
debut
itself.
Right,
yes,.
E
A
K
Can
I
also
ask
a
question
about
the
data
type,
because
I
see
that
protoba
field
is
encoded
in
in
the
hash
table,
the
same
way
that
we
encode
regular
string
Fields?
So
there
is
the
key
called
VB
and
then
value
is
the
protopuffin
coding?
Will
there
be
a
difference
if
a
different
data
type
is
used
for
protopuff
different
than
key
value
for
that
field
like
if
you
just
use
set
instead
of
H
set
or
something
else?
Oh.
B
In
my
opinion,
we
can
change
it.
Why
we
use
this
this
kind
of
hash
table,
because
we
just
want
to
keep
the
compatibility
with
the
typical
interface
compatibility
with
a
typical
Sonic
table,
because
the
innocent,
English
and
layer
we
use,
we
want
to
keep
the
same
interface
and
I
actually
I
did
some
I
did
some
experiment
about
that.
If
we
just
change
the
hash
table
to
the
packet
list,
it
can
all
we
can.
B
B
G
Oh
I
wanted
to
just
clarify.
There
was
a
comment
shortly
after
my
initial
comment
was
you
know
the
Asic
or
the
apdb
doesn't
have
to
be
on
the
dpu
it'll
be
in
the
host
or,
let's
say
the
the
switch,
but
that
seemed
like
that
assumptions
is
okay
solve
because
in
a
Smart
Switch
the
strong
central
processor
holds
the
redis
database
and
the
dpus
just
have
sync
DS
I
mean
then
that's
according
to
this
Smart
Switch
architecture
in
the
dash
hld.
You
know
you
can
see
that
and
that's
I'll
share
the
link.
G
Okay,
that's
good
to
good
to
articulate
that
and
that
that's
why
I'm
thinking,
maybe
a
diagram
showing
how
all
this
is
laid
out.
You
know
where
you
have
the
central.
You
have
an
app
DB
of
Asic
DBS.
You
have
two
different
configurations:
right:
Smart,
Switch
and
Standalone
dpu
for
the
appliance
and
how
these,
how
these
databases
lay
out
for
the
different
cases
I
think
would
be
nice
to
have.
G
We
need
the
context,
we
need
the
context
right.
I
mean
we're.
Looking
at
you
know
one
optimization
here
without
understanding
the
big
picture
at
least
I'm,
not
I,
don't
know
if
I'm
alone
in
that,
but
you
know
we
probably
need
a
refresher
or
a
high
level
overview
of
how
this
fits
in
and
what
the
objective
is.
You
know
there's
a
there's,
a
background
conversation
that
we're
not
all
privy
to,
and
it
would
be
nice
nice
to
have
a
little
background.
C
So
one
thing
these
tables
shows
is
the.
Unfortunately,
it's
kind
of
hidden
behind
the
red
box
is
the
pair
card
usage,
which
is
standalone.
Dpu
number
that
I'm
sure
vendors
will
like
to
know
right.
It's
like
if
you
look
at
the
table.
Size
per
card
is
what
we
care
like
vendors.
We
care
about
because
that
database
size
is
on
the
dpu
right
am
I
wrong
about
that.
G
C
G
No,
no
no
asicdb
is
isn't
that
stored
in
correct
me
if
I'm
wrong,
but
isn't
that
stored
has
a
bunch
of
key
value,
pairs
or
database
entries.
Let's
say
in
redis
that
represents
intended
configuration
of
the
abstract
data
plane
right,
yes,
transformed
and
stored,
so
you
might
take
one
appdb
entry.
It
might
turn
into
unknown
number
of
basic
DB
entries
when
it's
expanded
and
inflated
right
translated.
G
C
G
It
gets
sent
down
right
on
like
an
event
level
down
to
the
vendors
and
the
vendor
might
store
internally.
However,
they
want,
if
you
have
to
read
it
back,
you
have
to
store
it
in
a
form
that
can
be
transformed
back.
I
know
you
raised
the
question
many
months
ago.
Do
we
have
to
be
able
to
do
a
git
on
all
these
entries,
because
that
means
that
we
have
to
store
something?
That's
it
can
be
losslessly
converted
back
into
the
read
back
version
right.
G
Remember
that
conversation
Vincent,
that
you
started.
You
were
concerned
about
having
a
support,
a
get
operation
on
Sonic
on
Asic
entries,
okay,
the
cost
of
storing
it
in
some
form,
some
ephemeral
form
in
the
dpu
might
be
high.
If
you
have
to
be
able
to
set
it
provide
a
readable
value
back
equaling
to
the
set
value
right.
That's
not
that's
not
for
free!
C
A
C
D
G
But
yeah,
so
this
is
kind
of
an
early
ask
quite
some
time
ago.
You
know
by
the
community
various
people
saying
at
some
point.
We
need
some
kind
of
a
footprint
just
so
we
stay
out
of
trouble
and
I
I
think
it
would
be
a
mistake
to
optimize
one
portion
of
this
without
understanding
the
whole
thing
again.
G
I
know
I'm
beating
this
to
death,
but
if
we
already
have
a
dash
org
and
we
can
apply
a
large-scale
configuration
to
the
appdb,
we
should
very
easy
to
be
able
to
say
here's
the
here's,
the
memory
size
for
full
Hero,
Test,
config
or
full
Dash
config,
or
a
baby
Hero,
whatever
some
scaled
number
and
say:
okay,
it's
X
gigabytes
for
this
config.
What
do
people
think.
D
But
do
you
still
I
mean
the
memory
of
footprint
is
still
separate
from
the
you
know
the
door
spawn
the
API
formats
right,
so
I'm
I'm
still
having
a
you
know
difficult
to
understand.
You
know
why
these
you
know
this
might
be
related,
but
it's
not
tightly
coupled
right,
so
you
can
choose
whatever
the
noise
button
format
and
then
having
a
separate.
You
know,
memory,
consumption
evaluations
well,.
G
It's
kind
of
like
you,
can't
see
the
forest
for
the
trees
because
we're
this
is
a
tree.
We're
talking
about.
What's
the
forest,
look
like
how
many
acres
is
it.
You
know,
that's
the
kind
of
thing
I'm
trying
to
get
at.
Do
we
actually
have
a
a
grasp
of
this
size
of
the
memory
footprint
of
a
full
Dash
config
in
redis,
regardless.
D
G
I
understand,
but
there's
the
elephant
in
the
room.
The
elephant
is
the
size
of
the
memory,
so
my
concern
is
we're
going
to
get
really
clever
about
optimizing,
some
Northbound
API
that
can't
be
applied
to
a
database,
that's
already
larger
than
memory.
It's
the
elephant
in
the
room
I'm
talking
about
it's,
it's
not
directly
related,
but
it
seems
like
avoiding
it.
I
feel
like
we're,
avoiding
the
elephant
in
the
room.
J
I
mean
Chris
Chris
question
for
you.
Are
you
saying
that
in
the
standalone
Appliance
type
model,
if
you
were
to
push
all
config
DBA
app
DB
and
Asic
DB
you're,
trying
to
figure
out
what
it's
going
to
look
like
what
the
the
the
limitations
are
are
in
the
model
that
at
least
Prince
that
Gohan
are
saying
is
that
the
config,
DB
and
appdb
is
going
to
stay
on
the
host
and
and
then
all
the
other
stuff
will
stay
on
the
dpu
right.
D
I
D
In
current,
you
know
in
in
some
current
skills
right
so
but
at
least
we
put
out
you
know
our
current
evaluation
of
the
memory
consumption.
If
we
want
to
install
Sonic
what
would
be
the
memory
consumption
on
those
right
so
and
they
will
continue
discussing
you
know
what
options
we
have
on
their
supplies
cases
but
I
think
on
the
Smart
Switch
cases.
You
know
we
already
have
a
proposal
on
how
we
can
store
those
things
in
the
Main
Street
CPUs.
I
D
D
L
D
D
F
L
F
Yeah
from
from
this
slide,
it
will
be
good
to
have
just
one
context
of
just
one
card
right
and
then
the
question
becomes
that,
okay,
if
your
assumption
base
assumption
the
best
premise
is
that
host
will
store
certain
data
and
TPU
will
store
certain
data.
Then
you
know
it
will
be
a
little
bit
confusing
if
it
is
a
single
Standalone,
Appliance
use
case.
F
D
L
B
B
Low
limitation
I
mean,
but
if
we
use
some
wait,
I
I
another
experiment
is
about
to
use
the
memory
we
we
have
this
attribute
value
and
we
use
something:
some
GTA
camera
camera
as
the
algorithm
to
compress
the
data.
We
were
also
got
about
30
gigabytes
I.
Remember
that
yeah
I
have
some
data
about
that.
D
D
Then
you
know
the
then
you
can
calculate
the
efficiency
I.
Think
that
addressed
the
question.
Okay,
so
let's
say
you
know:
if
we
achieve
a
you
know,
70
percent
of
efficiency
or
80
percent
of
efficiencies.
Then
you
know,
then
then
people
know
it's
okay.
If
we
want
to
do
some
other
schemes,
what
could
be
the
potential
savings
right,
so
I.
B
D
D
Yeah
I
think
you
know
yeah.
Maybe
you
need
to
check
and
see
if
there's
any
internal
data
on
this
Excel
sheet,
if
there's
no,
then
we
can,
you
know,
do
some
do
some
work
and
get
this
Excel
sheet
and
published
right.
So
then
people
can
can
analyze
and
check
that
that
yeah,
that
is
certainly
doable
thanks.