I was testing SNAT with Trex that generates multi million sessions and
these sessions are allocated from VPP pool. I realized that when allocated
memory in "show memory" command result is near 4GB, system crashes. So I
compiled VPP with Dclib_vec64 option to have more than four Gigabytes of
main heap. But it caused to have high drop rates so that the throughput was
about 1000 times slower.
When I reviewed the code to find the problem I started from inserting about
1000 items in a hash table and reached mheap_get_search_free_bin function
in mheap.c file that could not fit the requested allocated object in free
objects as new items was adding. So the loop increasingly called.
/* Find an object that is large enough with correct alignment at given
alignment offset. */ while (1){...}
I founded that the requested object is smaller that free object but it
could not be fitted because of alignment offset.
Thanks
Juan
Best Regards,
Juan Salmon.
On Sun, May 7, 2017 at 5:04 PM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:
> You’ll need to characterize what you’re seeing better than “multiple time
> slower” before it would be worth speculating on what’s going on.
>
>
>
> We do not routinely test vpp when compiled w/ -DCLIB_VEC64.
>
>
>
> Can you describe the use-case which requires a main heap larger than 4gb?
>
>
>
> Thanks… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Juan Salmon
> *Sent:* Sunday, May 7, 2017 7:31 AM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] vpp with 64 bit vec
>
>
>
> Hi,
>
> I compiled VPP with Dclib_vec64 option to have more than four Gigabyte
> heap size.
>
> It works correctly but multiple time slower than 32 bit version.
>
> It seems that inserting data in hash tables caused this problem.
>
> Is there any idea?
>
>
>
> Best Regards,
>
> Juan Salmon.
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
