Did you throw away /dev/shm/{db, global_vm, vpe-api} before trying to switch 
from 32-bit to 64-bit vector lengths?

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of mahdi akrami
Sent: Sunday, October 16, 2016 9:46 AM
To: Damjan Marion (damarion) <damar...@cisco.com>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] compile vpp with CLIB_VEC64 > 0


In build-data/platforms/vpp.mk<http://vpp.mk/> there are three lines with 
CFLAGS key word :

"vpp_debug_TAG_CFLAGS = -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 -march=$(MARCH) \
               -fstack-protector-all -fPIC -Werror -DCLIB_VEC64=1
vpp_debug_TAG_LDFLAGS = -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 -march=$(MARCH) \
               -fstack-protector-all -fPIC -Werror

vpp_TAG_CFLAGS = -g -O2 -DFORTIFY_SOURCE=2 -march=$(MARCH) -mtune=$(MTUNE) \
               -fstack-protector -fPIC -Werror -DCLIB_VEC64=1
vpp_TAG_LDFLAGS = -g -O2 -DFORTIFY_SOURCE=2 -march=$(MARCH) -mtune=$(MTUNE) \
               -fstack-protector -fPIC -Werror

vpp_gcov_TAG_CFLAGS = -g -O0 -DCLIB_DEBUG -march=$(MARCH) \
               -fPIC -Werror -fprofile-arcs -ftest-coverage -DCLIB_VEC64=1
vpp_gcov_TAG_LDFLAGS = -g -O0 -DCLIB_DEBUG -march=$(MARCH) \
               -fPIC -Werror -coverage"

As you can see, I added -DCLIB_VEC64=1 to the end of these lines and recompiled 
VPP. Now when I run VPP I counter following errors:

vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins
load_one_plugin:92: Loaded plugin: /usr/lib/vpp_plugins/ioam_pot_plugin.so
load_one_plugin:92: Loaded plugin: /usr/lib/vpp_plugins/lb_plugin.so
load_one_plugin:92: Loaded plugin: /usr/lib/vpp_plugins/snat_plugin.so
load_one_plugin:92: Loaded plugin: /usr/lib/vpp_plugins/ila_plugin.so
0: svm_map_region:688: region /global_vm mutex held by dead pid 47797, tag 2, 
force unlock
0: svm_map_region:696: recovery: attempt to re-lock region

The bt output of gdb is here:

#0  remove_free_elt (e=0x30004ff0, e=0x30004ff0, bin=1, v=0x30005000) at 
#1  mheap_get_search_free_bin (align_offset=0, align=8, 
n_user_data_bytes_arg=<synthetic pointer>, bin=1, v=<optimized out>) at 
#2  mheap_get_search_free_list (align_offset=0, align=8, 
n_user_bytes_arg=<synthetic pointer>, v=<optimized out>) at 
#3  mheap_get_aligned (v=<optimized out>, n_user_data_bytes=<optimized out>, 
n_user_data_bytes@entry=22, align=<optimized out>, align@entry=8, 
align_offset=0, align_offset@entry=8, 
offset_return=offset_return@entry=0x7fff05a168c8) at 
#4  0x00007ffff6834b13 in clib_mem_alloc_aligned_at_offset (align_offset=8, 
align=8, size=22) at /root/vpp_64bit/build-data/../vppinfra/vppinfra/mem.h:87
#5  vec_resize_allocate_memory (v=v@entry=0x0, 
length_increment=length_increment@entry=14, data_bytes=22, 
header_bytes=<optimized out>, header_bytes@entry=0, 
data_align=data_align@entry=8) at 
#6  0x00007ffff67fe4f8 in _vec_resize (data_align=<optimized out>, 
header_bytes=<optimized out>, data_bytes=<optimized out>, 
length_increment=<optimized out>, v=<optimized out>) at 
#7  do_percent (va=0x7fff05a16a08, fmt=<optimized out>, _s=<synthetic pointer>) 
at /root/vpp_64bit/build-data/../vppinfra/vppinfra/format.c:340
#8  va_format (s=0x0, fmt=<optimized out>, va=va@entry=0x7fff05a16a08) at 
#9  0x00007ffff67fe067 in format (s=s@entry=0x0, fmt=fmt@entry=0x7ffff684233f 
"%s:") at /root/vpp_64bit/build-data/../vppinfra/vppinfra/format.c:422
#10 0x00007ffff67f9ab0 in _clib_error (how_to_die=how_to_die@entry=4, 
function_name=function_name@entry=0x7ffff6e6c137 <__FUNCTION__.11857> 
"svm_map_region", line_number=line_number@entry=703, 
fmt=fmt@entry=0x7ffff6e6bf70 "recovery: attempt svm_data_region_map") at 
#11 0x00007ffff6e66d64 in svm_map_region (a=0x7fff05a16e10) at 
#12 0x00007ffff6e66fc1 in svm_region_init_internal (a=0x7fff05a16e10) at 
#13 0x00007ffff6e671e5 in svm_region_init_args (a=a@entry=0x7fff05a16e10) at 
#14 0x00007ffff79b82cc in vlibmemory_init (vm=vm@entry=0xaecb40 
<vlib_global_main>) at 
#15 0x000000000059327f in gmon_init (vm=0xaecb40 <vlib_global_main>) at 
#16 0x00007ffff75429dd in vlib_call_init_exit_functions (vm=vm@entry=0xaecb40 
<vlib_global_main>, head=<optimized out>, call_once=call_once@entry=1) at 
#17 0x00007ffff7542a23 in vlib_call_all_init_functions (vm=vm@entry=0xaecb40 
<vlib_global_main>) at /root/vpp_64bit/build-data/../vlib/vlib/init.c:75
#18 0x00007ffff7546593 in vlib_main (vm=vm@entry=0xaecb40 <vlib_global_main>, 
input=input@entry=0x7fff05a16fa0) at 
#19 0x00007ffff77a4dc3 in thread0 (arg=11455296) at 
#20 0x00007ffff6808750 in clib_calljmp () at 
#21 0x00007fffffffce30 in ?? ()
#22 0x00007ffff77a559f in vlib_unix_main (argc=<optimized out>, argv=<optimized 
out>) at /root/vpp_64bit/build-data/../vlib/vlib/unix/main.c:488
#23 0x0000000000000000 in ?? ()

Thanks in advance

On Mon, Oct 10, 2016 at 2:01 PM, Damjan Marion (damarion) 
<damar...@cisco.com<mailto:damar...@cisco.com>> wrote:

Try to add  –DCLIB_VEC64=1  to CFLAGS in 
build-data/platforms/vpp.mk<http://vpp.mk> ..

From: mahdi akrami <akram...@gmail.com<mailto:akram...@gmail.com>>
Date: Monday, 10 October 2016 at 12:25
To: "Damjan Marion (damarion)" <damar...@cisco.com<mailto:damar...@cisco.com>>
Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
Subject: Re: [vpp-dev] compile vpp with CLIB_VEC64 > 0

Hi Damjan,
Yes I know. I mean 10 huge pages of size 1G!
So 10 huge pages is high and I should decrease it.
If I want to maintain a very large hash tables that need more than 4G heap, 
what should I do?

On Mon, Oct 10, 2016 at 1:06 PM, Damjan Marion (damarion) 
<damar...@cisco.com<mailto:damar...@cisco.com>> wrote:
Dear Mahdi,

There is no 10G hugepages. You mean 1G ?

dpdk socket-mem is only used to allocate buffer memory. It is not used for heap 
so no sense in increasing it.

May I ask why do you need such a big heap?



> On 10 Oct 2016, at 08:01, mahdi akrami 
> <akram...@gmail.com<mailto:akram...@gmail.com>> wrote:
> Hi,
> VPP encountered out of memory error. I want to know where the total amount of 
> memory is assigned to VPP? I configured VPP as follow:
> dpdk {
>   socket-mem 10240
> }
> heapsize {
>   4000M
> }
> So VPP can use up to 10G hugepages and heap of 4000M size. What is exactly 
> heap size hear means? Is it total amount of memoty that VPP can use?
> Another question is that how can I compile VPP  with CLIB_VEC64 > 0, so that 
> I can set heap size more than 4G?
> Thanks in advance for your response
> Mahdi
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev

vpp-dev mailing list

Reply via email to