Re: [vpp-dev] dpdk-20.02 compile error for Intel atom

[mythosmonkeyking]

hi，Benoit Ganne,
When I use 'silvermont', there are still errors.As follows:

[mythos@localhost dpdk-20.02]$ ls -l 
config/defconfig_x86_64-silvermont-linux-gcc
lrwxrwxrwx 1 mythos mythos 40 Apr 18 10:10 
config/defconfig_x86_64-silvermont-linux-gcc -> 
defconfig_x86_64-silvermont-linuxapp-gcc
[mythos@localhost dpdk-20.02]$ cat mk/machine/silvermont/rte.vars.mk
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation

#
# machine:
#
#   - can define ARCH variable (overridden by cmdline value)
#   - can define CROSS variable (overridden by cmdline value)
#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
#   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
#   - can define CPU_CFLAGS variable (overridden by cmdline value) that
#     overrides the one defined in arch.
#   - can define CPU_LDFLAGS variable (overridden by cmdline value) that
#     overrides the one defined in arch.
#   - can define CPU_ASFLAGS variable (overridden by cmdline value) that
#     overrides the one defined in arch.
#   - may override any previously defined variable
#

# ARCH =
# CROSS =
# MACHINE_CFLAGS =
# MACHINE_LDFLAGS =
# MACHINE_ASFLAGS =
# CPU_CFLAGS =
# CPU_LDFLAGS =
# CPU_ASFLAGS =

MACHINE_CFLAGS = -march=silvermont
[mythos@localhost dpdk-20.02]$ make config T=x86_64-silvermont-linux-gcc 
RTE_KERNELDIR=/home/mythos/kernel/linux-3.10 V=1
make -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/mk/rte.sdkconfig.mk config
if [ 
"/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/config/defconfig_x86_64-silvermont-linux-gcc"
 != "" -a -f 
"/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/config/defconfig_x86_64-silvermont-linux-gcc"
 ]; then \
cc -E -undef -P -x assembler-with-cpp \
`cat /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/VERSION | \
sed -e 's/-rc/.-rc./' -e 's/$/..99/' | \
awk -F '.' '{print "-D__YEAR="int($1), "-D__MONTH="int($2), 
"-D__MINOR="int($3), "-D__SUFFIX=\""$4"\"", "-D__RELEASE="int($5)}'` \
-ffreestanding \
-o /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/config/defconfig_x86_64-silvermont-linux-gcc
 ; \
config=$(cat /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp) ; \
echo "$config" | awk -F '=' 'BEGIN {i=1} \
/^#/ {pos[i++]=$0} \
!/^#/ {if (!s[$1]) {pos[i]=$0; s[$1]=i++} \
else {pos[s[$1]]=$0}} END \
{for (j=1; j /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp ; \
if ! cmp -s /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config; then \
cp /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config ; \
cp /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config.orig ; \
fi ; \
rm -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/.config_tmp ; \
else \
make -rRf /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/mk/rte.sdkconfig.mk 
notemplate; \
fi
Configuration done using x86_64-silvermont-linux-gcc
[mythos@localhost dpdk-20.02]$ make V=1
make -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/mk/rte.sdkconfig.mk 
checkconfig
make -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/mk/rte.sdkconfig.mk \
headerconfig NODOTCONF=1
make -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/mk/rte.sdkbuild.mk all
cc1: error: bad value (silvermont) for -march= switch
cc1: warning: unrecognized command line option "-Wno-address-of-packed-member" 
[enabled by default]
== Build lib
make S=lib -f /home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/lib/Makefile -C 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/build/lib all
cc1: error: bad value (silvermont) for -march= switch
cc1: warning: unrecognized command line option "-Wno-address-of-packed-member" 
[enabled by default]
== Build lib/librte_kvargs
cc1: error: bad value (silvermont) for -march= switch
cc1: warning: unrecognized command line option "-Wno-address-of-packed-member" 
[enabled by default]
gcc -Wp,-MD,./.rte_kvargs.o.d.tmp  -m64 -pthread 
-I/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/lib/librte_eal/linux/eal/include 
 -march=silvermont   
-I/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/include 
-DRTE_USE_FUNCTION_VERSIONING -include 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/build/include/rte_config.h 
-D_GNU_SOURCE -W -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align 
-Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef 
-Wwrite-strings -Wdeprecated -Wno-missing-field-initializers 
-Wno-address-of-packed-member 
-I/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/lib/librte_kvargs -O3 
-I/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/lib/librte_eal/common/include    
-o rte_kvargs.o -c 
/home/mythos/dpdk/dpdk-20.02-atom/dpdk-20.02/lib/librte_kvargs/rte_kvargs.c

[vpp-dev] New calico-vpp alpha version released

[Jerome Tollet via lists.fd.io]

Hello,
A new (alpha) version of calico-vpp was released today. Main addition is 
support for Kubernetes ipv6 services.
Feel free to give it a try : https://github.com/calico-vpp/calico-vpp
Congrats to @Aloys Augustin (aloaugus) & @Nathan 
Skrzypczak !
Regards,
Jerome
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16151): https://lists.fd.io/g/vpp-dev/message/16151
Mute This Topic: https://lists.fd.io/mt/73250268/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] worker barrier state

[Christian Hopps]

Hi Neale,

Comments also inline...

Neale Ranns (nranns)  writes:


Hi Chris,

Comments inline...

On 15/04/2020 15:14, "Christian Hopps"  wrote:

Hi Neale,

I agree that something like 4, is probably the correct approach. I had a side-meeting 
with some of the ARM folks (Govind and Honnappa), and we thought using a generation 
number for the state rather than just waiting "long-enough" to recycle it could 
work. The generation number would be the atomic value associated with the state. So 
consider this API:

 - MP-safe pools store generation numbers alongside each object.
 - When you allocate a new object from the pool you get an index and 
generation number.
 - When storing the object index you also save the generation number.
 - When getting a pointer to the object you pass the API the index and 
generation number and it will return NULL if the generation number did not 
match the one stored with the object in the pool.
 - When you delete a pool object its generation number is incremented (with 
barrier).

The size of the generation number needs to be large enough to guarantee there is no 
wrap with objects still in the system that have stored the generation number. Technically 
this is a "long-enough" aspect of the scheme. :) One could imagine using less 
than 64 bits for the combination of index and generation, if that was important.

It's a good scheme, I like it.
I assume the pool indices would be 64 bit and the separation between vector 
index and generation would be hidden from the user. Maybe a 32 bit value would 
suffice in most cases, but why skimp...


I was thinking to keep the index and generation number separate at the most 
basic API, to allow for selecting the size of the each independently and for 
efficient storage. I'm thinking for some applications one might want to do 
something like

cacheline_packed_struct {
   ...
   u32 foo_index;
   u32 bar_index;
   u16 foo_gen;
   u16 bar_gen;
   ...
};

a set of general purpose macros could be created for combining the 2 values 
into a single integer value though.


The advantage over just waiting N seconds to recycle the index is that the 
system scales better, i.e., if you just wait N seconds to reuse, and are 
creating and deleting objects at a significant rate, your pool can blow up in 
the N seconds of time. With the generation number this is not a problem as you 
can re-use the object immediately. Another advantage is that you don't have to 
have the timer logic (looping per pool or processing all pools) to free up old 
indices.

Yes, for my time based scheme, the size of the pool will become dependent on 
some integration over a rate of change, which is not deterministic, which is 
not great, but I don't suppose all APIs are subject to large churn.
With the generation scheme the pool always requires more memory, since you're 
storing a generation value for each index, but being a deterministic size (even 
though probably bigger), I'd probably take that.
I wouldn't use timer logic in my scheme. I'd make the pool's free-list a fifo (as 
opposed to the stack it is today) and each entry in the list has the index and the 
time it was added. If t_now - t_head < t_wrap I can pull from the free-list, 
else the pool needs to grow.


FWIW, I think the space used for the timestamp would be similar to the space 
used for the generation number, probably it's a wash.


The generation number scheme will still need the thread barrier to 
increment the generation number to make sure no-one is using the object in 
parallel. But this is a common problem with deleting non-reference-counted 
shared state I believe.

I don't think you strictly need the barrier, you can still use a 
make-before-break update. One downside of the generation approach is that nodes 
that try and fetch the state using the index will get NULL, so the only option 
is to drop, as opposed to what the make-before-break change determined. Mind 
you, this is probably fine for most practical purposes. Again if we're talking 
SAs, then at this point the SA is decoupled from the graph (i.e. it's no longer 
protecting the tunnel or it's not linked to a policy in the SPD), so drop is 
all we can do anyway.


You need the barrier to make sure no in-flight packets are concurrently using 
the object the index/gen pointed at. Strictly speaking, you could increment the 
generation number w/o the barrier, but then you have to hold the barrier during 
free/re-use of the pool object. The beauty of the generation number is that you 
only hold the barrier while you increment it, and the free/re-use of the object 
is done outside the barrier.


I see it as a trade-off between a cost for every packet forwarded versus how 
many may be dropped during API calls. I wouldn't want the scheme employed to 
ensure safe delete to affect the overall packet through put - most of the time 
I'm not changing the state...

Now we have a few potential schemes in mind, IIRC