Hi,
In build-data/platforms/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> wrote:
>
>
> Try to add –DCLIB_VEC64=1 to CFLAGS in build-data/platforms/vpp.mk ..
>
>
>
>
>
> *From: *mahdi akrami <akram...@gmail.com>
> *Date: *Monday, 10 October 2016 at 12:25
> *To: *"Damjan Marion (damarion)" <damar...@cisco.com>
> *Cc: *"vpp-dev@lists.fd.io" <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> 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> 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
> > 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
