Thanks to Dave comment, VPP now runs without problem and routing
functionality works. But when I enable SNAT plugin, it works very slowly.
Is there any extra configurations that I missed?
Thanks
Mahdi
On Sun, Oct 16, 2016 at 6:00 PM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:
> 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 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
