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
Hi,
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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/mheap.c:222
#1 mheap_get_search_free_bin (align_offset=0, align=8,
n_user_data_bytes_arg=<synthetic pointer>, bin=1, v=<optimized out>) at
/root/vpp_64bit/build-data/../vppinfra/vppinfra/mheap.c:488
#2 mheap_get_search_free_list (align_offset=0, align=8,
n_user_bytes_arg=<synthetic pointer>, v=<optimized out>) at
/root/vpp_64bit/build-data/../vppinfra/vppinfra/mheap.c:552
#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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/mheap.c:690
#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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/vec.c:59
#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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/vec.h:142
#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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/format.c:403
#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
/root/vpp_64bit/build-data/../vppinfra/vppinfra/error.c:120
#11 0x00007ffff6e66d64 in svm_map_region (a=0x7fff05a16e10) at
/root/vpp_64bit/build-data/../svm/svm.c:703
#12 0x00007ffff6e66fc1 in svm_region_init_internal (a=0x7fff05a16e10) at
/root/vpp_64bit/build-data/../svm/svm.c:757
#13 0x00007ffff6e671e5 in svm_region_init_args (a=a@entry=0x7fff05a16e10) at
/root/vpp_64bit/build-data/../svm/svm.c:835
#14 0x00007ffff79b82cc in vlibmemory_init (vm=vm@entry=0xaecb40
<vlib_global_main>) at
/root/vpp_64bit/build-data/../vlib-api/vlibmemory/memory_vlib.c:1194
#15 0x000000000059327f in gmon_init (vm=0xaecb40 <vlib_global_main>) at
/root/vpp_64bit/build-data/../vpp/vpp-api/gmon.c:183
#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
/root/vpp_64bit/build-data/../vlib/vlib/init.c:57
#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
/root/vpp_64bit/build-data/../vlib/vlib/main.c:1620
#19 0x00007ffff77a4dc3 in thread0 (arg=11455296) at
/root/vpp_64bit/build-data/../vlib/vlib/unix/main.c:432
#20 0x00007ffff6808750 in clib_calljmp () at
/root/vpp_64bit/build-data/../vppinfra/vppinfra/longjmp.S:110
#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>"
<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?
Thanks
Mahdi
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?
Thanks,
Damjan
> 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
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
