test: linux-dpdk: increase number of huge pages

Message ID 1488389567-9660-1-git-send-email-balakrishna.garapati@linaro.org
State New
Headers show

Commit Message

Krishna Garapati March 1, 2017, 5:32 p.m.
Also sets 2MB as default page size instead of 1G.

Signed-off-by: Balakrishna Garapati <balakrishna.garapati@linaro.org>
---
 test/linux-dpdk/wrapper-script.sh | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

--
1.9.1

Comments

Zoltan Kiss March 1, 2017, 9:14 p.m. | #1
This was set to use 1G pages because some of the unit tests need a lot 
of _contiguous_ memory. If you use 2M pages, it might happen that pool 
create fails, causing random unit test failures. Unless DPDK have 
changed it's memory management.

On 01/03/17 18:32, Balakrishna Garapati wrote:
> Also sets 2MB as default page size instead of 1G.
>
> Signed-off-by: Balakrishna Garapati <balakrishna.garapati@linaro.org>
> ---
>   test/linux-dpdk/wrapper-script.sh | 17 +++++------------
>   1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/test/linux-dpdk/wrapper-script.sh b/test/linux-dpdk/wrapper-script.sh
> index c43520f..485c1ba 100755
> --- a/test/linux-dpdk/wrapper-script.sh
> +++ b/test/linux-dpdk/wrapper-script.sh
> @@ -43,21 +43,14 @@ if [ ! -d $HUGEPAGEDIR ]; then
>   	sudo mkdir -p $HUGEPAGEDIR
>   fi
>   echo "Mounting hugetlbfs"
> -export SIZE=1G
> -export SIZE_KB=1048576
> -export RESERVE=1
> +export SIZE=2MB
> +export SIZE_KB=2048
> +export RESERVE=1024
>   mount_and_reserve
>   res=$?
>   if [ $res -ne 0 ]; then
> -	export SIZE=2MB
> -	export SIZE_KB=2048
> -	export RESERVE=256
> -	mount_and_reserve
> -	res=$?
> -	if [ $res -ne 0 ]; then
> -		echo "ERROR: can't mount hugepages with any size"
> -		exit $res
> -	fi
> +	echo "ERROR: can't mount hugepages with 2MB size"
> +	exit $res
>   fi
>   echo "running $1!"
>   if [ ${1: -3} == ".sh" ]
> --
> 1.9.1
>
> _______________________________________________
> lng-odp-dpdk mailing list
> lng-odp-dpdk@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp-dpdk
Krishna Garapati March 2, 2017, 7:27 a.m. | #2
On 1 March 2017 at 22:14, Zoltan Kiss <zoltan.kiss@schaman.hu> wrote:

> This was set to use 1G pages because some of the unit tests need a lot of
> _contiguous_ memory. If you use 2M pages, it might happen that pool create
> fails, causing random unit test failures. Unless DPDK have changed it's
> memory management.


Seems like people have issues at least from Nokia using 1G as default huge
pages causing failure or segfaults from tests with christoph's ishm
changes. That's why I have changed the default to 2MB. My system doesn't
have 1G and validation all ways creates 2MB pages and haven't seen any
issue so far.

Currently a new validation test ( iplookuptable ) is failing because
rte_mempool_create doesn't have enough huge pages (current default is 256
for 2MB). That's why I have increased the no.of huge pages. Haven't gone
through DPDK memory management on newer release.

/Krishna


>
>
> On 01/03/17 18:32, Balakrishna Garapati wrote:
>
>> Also sets 2MB as default page size instead of 1G.
>>
>> Signed-off-by: Balakrishna Garapati <balakrishna.garapati@linaro.org>
>> ---
>>   test/linux-dpdk/wrapper-script.sh | 17 +++++------------
>>   1 file changed, 5 insertions(+), 12 deletions(-)
>>
>> diff --git a/test/linux-dpdk/wrapper-script.sh
>> b/test/linux-dpdk/wrapper-script.sh
>> index c43520f..485c1ba 100755
>> --- a/test/linux-dpdk/wrapper-script.sh
>> +++ b/test/linux-dpdk/wrapper-script.sh
>> @@ -43,21 +43,14 @@ if [ ! -d $HUGEPAGEDIR ]; then
>>         sudo mkdir -p $HUGEPAGEDIR
>>   fi
>>   echo "Mounting hugetlbfs"
>> -export SIZE=1G
>> -export SIZE_KB=1048576
>> -export RESERVE=1
>> +export SIZE=2MB
>> +export SIZE_KB=2048
>> +export RESERVE=1024
>>   mount_and_reserve
>>   res=$?
>>   if [ $res -ne 0 ]; then
>> -       export SIZE=2MB
>> -       export SIZE_KB=2048
>> -       export RESERVE=256
>> -       mount_and_reserve
>> -       res=$?
>> -       if [ $res -ne 0 ]; then
>> -               echo "ERROR: can't mount hugepages with any size"
>> -               exit $res
>> -       fi
>> +       echo "ERROR: can't mount hugepages with 2MB size"
>> +       exit $res
>>   fi
>>   echo "running $1!"
>>   if [ ${1: -3} == ".sh" ]
>> --
>> 1.9.1
>>
>> _______________________________________________
>> lng-odp-dpdk mailing list
>> lng-odp-dpdk@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp-dpdk
>>
>
>
Zoltan Kiss March 2, 2017, 8:13 a.m. | #3
On 02/03/17 08:27, Krishna Garapati wrote:
>
>
> On 1 March 2017 at 22:14, Zoltan Kiss <zoltan.kiss@schaman.hu 
> <mailto:zoltan.kiss@schaman.hu>> wrote:
>
>     This was set to use 1G pages because some of the unit tests need a
>     lot of _contiguous_ memory. If you use 2M pages, it might happen
>     that pool create fails, causing random unit test failures. Unless
>     DPDK have changed it's memory management. 
>
>
> Seems like people have issues at least from Nokia using 1G as default 
> huge pages causing failure or segfaults from tests
What are those issues? I think it would be better to solve them as 1G 
pages are an important usecase
> with christoph's ishm changes. That's why I have changed the default 
> to 2MB. My system doesn't have 1G and validation all ways creates 2MB 
> pages and haven't seen any issue so far.
If you reserved your pages at boot time, then it'll work. Our CI 
machines don't have that, so occasionally the test failed when the 
memory provided for the VM was too fragmented in the physical address space.
>
> Currently a new validation test ( iplookuptable ) is failing because 
> rte_mempool_create doesn't have enough huge pages (current default is 
> 256 for 2MB).
You can fix that in the "if" branch
> That's why I have increased the no.of huge pages. Haven't gone through 
> DPDK memory management on newer release.
>
> /Krishna
>
>
>
>     On 01/03/17 18:32, Balakrishna Garapati wrote:
>
>         Also sets 2MB as default page size instead of 1G.
>
>         Signed-off-by: Balakrishna Garapati
>         <balakrishna.garapati@linaro.org
>         <mailto:balakrishna.garapati@linaro.org>>
>         ---
>           test/linux-dpdk/wrapper-script.sh | 17 +++++------------
>           1 file changed, 5 insertions(+), 12 deletions(-)
>
>         diff --git a/test/linux-dpdk/wrapper-script.sh
>         b/test/linux-dpdk/wrapper-script.sh
>         index c43520f..485c1ba 100755
>         --- a/test/linux-dpdk/wrapper-script.sh
>         +++ b/test/linux-dpdk/wrapper-script.sh
>         @@ -43,21 +43,14 @@ if [ ! -d $HUGEPAGEDIR ]; then
>                 sudo mkdir -p $HUGEPAGEDIR
>           fi
>           echo "Mounting hugetlbfs"
>         -export SIZE=1G
>         -export SIZE_KB=1048576
>         -export RESERVE=1
>         +export SIZE=2MB
>         +export SIZE_KB=2048
>         +export RESERVE=1024
>           mount_and_reserve
>           res=$?
>           if [ $res -ne 0 ]; then
>         -       export SIZE=2MB
>         -       export SIZE_KB=2048
>         -       export RESERVE=256
>         -       mount_and_reserve
>         -       res=$?
>         -       if [ $res -ne 0 ]; then
>         -               echo "ERROR: can't mount hugepages with any size"
>         -               exit $res
>         -       fi
>         +       echo "ERROR: can't mount hugepages with 2MB size"
>         +       exit $res
>           fi
>           echo "running $1!"
>           if [ ${1: -3} == ".sh" ]
>         --
>         1.9.1
>
>         _______________________________________________
>         lng-odp-dpdk mailing list
>         lng-odp-dpdk@lists.linaro.org
>         <mailto:lng-odp-dpdk@lists.linaro.org>
>         https://lists.linaro.org/mailman/listinfo/lng-odp-dpdk
>         <https://lists.linaro.org/mailman/listinfo/lng-odp-dpdk>
>
>
>
Elo, Matias (Nokia - FI/Espoo) March 2, 2017, 8:27 a.m. | #4
> On 2 Mar 2017, at 10:13, Zoltan Kiss <zoltan.kiss@schaman.hu> wrote:
> 
> On 02/03/17 08:27, Krishna Garapati wrote:
>> 
>> 
>> On 1 March 2017 at 22:14, Zoltan Kiss <zoltan.kiss@schaman.hu <mailto:zoltan.kiss@schaman.hu>> wrote:
>> 
>>    This was set to use 1G pages because some of the unit tests need a
>>    lot of _contiguous_ memory. If you use 2M pages, it might happen
>>    that pool create fails, causing random unit test failures. Unless
>>    DPDK have changed it's memory management. 
>> 
>> Seems like people have issues at least from Nokia using 1G as default huge pages causing failure or segfaults from tests
> What are those issues? I think it would be better to solve them as 1G pages are an important usecase


The 1G pages are working fine everywhere else except for the new 'iplookuptable' validation test. On my system the test segfaults always at the end when it's trying to destroy the lookup table (odph_iplookup_table_destroy). With 2M pages everything is working nicely.

I've been trying to find the cause for this with no success. Any ideas what could be causing this?

-Matias


$ sudo ODP_PLATFORM_PARAMS="-n 4" ./iplookuptable
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
odp_init.c:125:odp_init_dpdk():arg[0]: odpdpdk
odp_init.c:125:odp_init_dpdk():arg[1]: -c
odp_init.c:125:odp_init_dpdk():arg[2]: 0x1
odp_init.c:125:odp_init_dpdk():arg[3]: -n
odp_init.c:125:odp_init_dpdk():arg[4]: 4
EAL: Detected 28 lcore(s)
EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs found for that size
EAL: Probing VFIO support...
[New Thread 0x7ffff6a55700 (LWP 26978)]
EAL: PCI device 0000:04:00.0 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device 0000:04:00.1 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device 0000:05:00.0 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device 0000:05:00.1 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device 0000:08:00.0 on NUMA socket 0
EAL:   probe driver: 8086:1583 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
EAL: PCI device 0000:08:00.1 on NUMA socket 0
EAL:   probe driver: 8086:1583 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
odp_init.c:138:odp_init_dpdk():rte_eal_init OK
../linux-generic/odp_system_info.c:97:default_huge_page_size():defaut hp size is 2048 kB
../linux-generic/odp_system_info.c:97:default_huge_page_size():defaut hp size is 2048 kB
../linux-generic/_ishm.c:1382:_odp_ishm_init_global():NOTE: No support for huge pages
../linux-generic/_ishmphy.c:63:_odp_ishmphy_book_va():VA Reserved: 0x7fffd6055000, len=0x20200000
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=0, fd=13
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=0}->fd=15
../linux-generic/_ishm.c:859:_odp_ishm_reserve():No huge pages, fall back to normal pages. check: /proc/sys/vm/nr_hugepages.
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=1, fd=14
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=1}->fd=16
odp_pool.c:85:odp_pool_init_global():
Pool init global
odp_pool.c:86:odp_pool_init_global():  pool_entry_s size     128
odp_pool.c:87:odp_pool_init_global():  pool_entry_t size     128
odp_pool.c:88:odp_pool_init_global():  odp_buffer_hdr_t size 320
odp_pool.c:89:odp_pool_init_global():
../linux-generic/odp_queue.c:111:odp_queue_init_global():Queue init ... ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=2, fd=15
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=2}->fd=17
../linux-generic/odp_queue.c:132:odp_queue_init_global():done
../linux-generic/odp_queue.c:133:odp_queue_init_global():Queue init global
../linux-generic/odp_queue.c:135:odp_queue_init_global():  struct queue_entry_s size 320
../linux-generic/odp_queue.c:137:odp_queue_init_global():  queue_entry_t size        320
../linux-generic/odp_queue.c:138:odp_queue_init_global():
../linux-generic/odp_schedule.c:252:schedule_init_global():Schedule init ... ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=3, fd=16
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=3}->fd=18
../linux-generic/odp_schedule.c:302:schedule_init_global():done
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=4, fd=17
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=4}->fd=19
PKTIO: initialized loop interface.
../linux-generic/odp_timer.c:1002:odp_timer_init_global():Using lock-less timer implementation
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=5, fd=18
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=5}->fd=20
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=6, fd=19
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=6}->fd=21
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=7, fd=20
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=7}->fd=22
odp_thread.c:166:odp_thread_init_local():There is a thread already running on core 0
../linux-generic/_ishm.c:1275:_odp_ishm_address():Request for address on an invalid block
../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client register: pid=26974 key=8, fd=21
../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1, key=8}->fd=23
odp_pool.c:367:odp_pool_create():type: buffer name: prefix_test_0_0 num: 8192 size: 6144 align: 64
odp_pool.c:435:odp_pool_create():Metadata size: 320, mb_size 6464
odp_pool.c:451:odp_pool_create():cache_size 512
odp_pool.c:495:odp_pool_create():Header/element/trailer size: 64/6464/64, total pool size: 54001664
odp_pool.c:367:odp_pool_create():type: buffer name: prefix_test_1_0 num: 1048576 size: 48 align: 64
odp_pool.c:435:odp_pool_create():Metadata size: 320, mb_size 384
odp_pool.c:451:odp_pool_create():cache_size 512
odp_pool.c:495:odp_pool_create():Header/element/trailer size: 64/384/0, total pool size: 469762048
Add IP prefix: 192.160.0.0/11
Lkp IP prefix: 192.168.0.1/32
Add IP prefix: 192.168.0.0/24
Lkp IP prefix: 192.168.0.1/32
Del IP prefix: 192.168.0.0/24
Lkp IP prefix: 192.168.0.1/32
Del IP prefix: 192.160.0.0/11

Thread 1 "iplookuptable" received signal SIGSEGV, Segmentation fault.
odph_iplookup_table_destroy (tbl=tbl@entry=0x7fffd5ed4000) at iplookuptable.c:552
552				if (subtree[j].child == 0)
(gdb) backtrace 
#0  odph_iplookup_table_destroy (tbl=tbl@entry=0x7fffd5ed4000) at iplookuptable.c:552
#1  0x000000000040a062 in test_ip_lookup_table () at iplookuptable.c:137
#2  main (argc=<optimized out>, argv=<optimized out>) at iplookuptable.c:158
Krishna Garapati March 2, 2017, 8:54 a.m. | #5
On 2 March 2017 at 09:27, Elo, Matias (Nokia - FI/Espoo) <
matias.elo@nokia-bell-labs.com> wrote:

>
> > On 2 Mar 2017, at 10:13, Zoltan Kiss <zoltan.kiss@schaman.hu> wrote:
> >
> > On 02/03/17 08:27, Krishna Garapati wrote:
> >>
> >>
> >> On 1 March 2017 at 22:14, Zoltan Kiss <zoltan.kiss@schaman.hu <mailto:
> zoltan.kiss@schaman.hu>> wrote:
> >>
> >>    This was set to use 1G pages because some of the unit tests need a
> >>    lot of _contiguous_ memory. If you use 2M pages, it might happen
> >>    that pool create fails, causing random unit test failures. Unless
> >>    DPDK have changed it's memory management.
> >>
> >> Seems like people have issues at least from Nokia using 1G as default
> huge pages causing failure or segfaults from tests
> > What are those issues? I think it would be better to solve them as 1G
> pages are an important usecase
>
>
> The 1G pages are working fine everywhere else except for the new
> 'iplookuptable' validation test. On my system the test segfaults always at
> the end when it's trying to destroy the lookup table
> (odph_iplookup_table_destroy). With 2M pages everything is working nicely.
>
> I've been trying to find the cause for this with no success. Any ideas
> what could be causing this?
>
> -Matias
>
>
> $ sudo ODP_PLATFORM_PARAMS="-n 4" ./iplookuptable
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> odp_init.c:125:odp_init_dpdk():arg[0]: odpdpdk
> odp_init.c:125:odp_init_dpdk():arg[1]: -c
> odp_init.c:125:odp_init_dpdk():arg[2]: 0x1
> odp_init.c:125:odp_init_dpdk():arg[3]: -n
> odp_init.c:125:odp_init_dpdk():arg[4]: 4
> EAL: Detected 28 lcore(s)
> EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs
> found for that size
>

Seems like you are using 2MB page size not 1G and they are not mounted as
well.

EAL: Probing VFIO support...
> [New Thread 0x7ffff6a55700 (LWP 26978)]
> EAL: PCI device 0000:04:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:10fb net_ixgbe
> EAL: PCI device 0000:04:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:10fb net_ixgbe
> EAL: PCI device 0000:05:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:10fb net_ixgbe
> EAL: PCI device 0000:05:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:10fb net_ixgbe
> EAL: PCI device 0000:08:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:1583 net_i40e
> PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
> EAL: PCI device 0000:08:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:1583 net_i40e
> PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505
> odp_init.c:138:odp_init_dpdk():rte_eal_init OK
> ../linux-generic/odp_system_info.c:97:default_huge_page_size():defaut hp
> size is 2048 kB
> ../linux-generic/odp_system_info.c:97:default_huge_page_size():defaut hp
> size is 2048 kB

../linux-generic/_ishm.c:1382:_odp_ishm_init_global():NOTE: No support for
> huge pages
> ../linux-generic/_ishmphy.c:63:_odp_ishmphy_book_va():VA Reserved:
> 0x7fffd6055000, len=0x20200000
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=0, fd=13
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=0}->fd=15
> ../linux-generic/_ishm.c:859:_odp_ishm_reserve():No huge pages, fall back
> to normal pages. check: /proc/sys/vm/nr_hugepages.
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=1, fd=14
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=1}->fd=16
> odp_pool.c:85:odp_pool_init_global():
> Pool init global
> odp_pool.c:86:odp_pool_init_global():  pool_entry_s size     128
> odp_pool.c:87:odp_pool_init_global():  pool_entry_t size     128
> odp_pool.c:88:odp_pool_init_global():  odp_buffer_hdr_t size 320
> odp_pool.c:89:odp_pool_init_global():
> ../linux-generic/odp_queue.c:111:odp_queue_init_global():Queue init ...
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=2, fd=15
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=2}->fd=17
> ../linux-generic/odp_queue.c:132:odp_queue_init_global():done
> ../linux-generic/odp_queue.c:133:odp_queue_init_global():Queue init global
> ../linux-generic/odp_queue.c:135:odp_queue_init_global():  struct
> queue_entry_s size 320
> ../linux-generic/odp_queue.c:137:odp_queue_init_global():  queue_entry_t
> size        320
> ../linux-generic/odp_queue.c:138:odp_queue_init_global():
> ../linux-generic/odp_schedule.c:252:schedule_init_global():Schedule init
> ... ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD
> client register: pid=26974 key=3, fd=16
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=3}->fd=18
> ../linux-generic/odp_schedule.c:302:schedule_init_global():done
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=4, fd=17
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=4}->fd=19
> PKTIO: initialized loop interface.
> ../linux-generic/odp_timer.c:1002:odp_timer_init_global():Using lock-less
> timer implementation
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=5, fd=18
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=5}->fd=20
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=6, fd=19
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=6}->fd=21
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=7, fd=20
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=7}->fd=22
> odp_thread.c:166:odp_thread_init_local():There is a thread already
> running on core 0
> ../linux-generic/_ishm.c:1275:_odp_ishm_address():Request for address on
> an invalid block
> ../linux-generic/_fdserver.c:277:_odp_fdserver_register_fd():FD client
> register: pid=26974 key=8, fd=21
> ../linux-generic/_fdserver.c:461:handle_request():storing {ctx=1,
> key=8}->fd=23
> odp_pool.c:367:odp_pool_create():type: buffer name: prefix_test_0_0 num:
> 8192 size: 6144 align: 64
> odp_pool.c:435:odp_pool_create():Metadata size: 320, mb_size 6464
> odp_pool.c:451:odp_pool_create():cache_size 512
> odp_pool.c:495:odp_pool_create():Header/element/trailer size: 64/6464/64,
> total pool size: 54001664
> odp_pool.c:367:odp_pool_create():type: buffer name: prefix_test_1_0 num:
> 1048576 size: 48 align: 64
> odp_pool.c:435:odp_pool_create():Metadata size: 320, mb_size 384
> odp_pool.c:451:odp_pool_create():cache_size 512
> odp_pool.c:495:odp_pool_create():Header/element/trailer size: 64/384/0,
> total pool size: 469762048
> Add IP prefix: 192.160.0.0/11
> Lkp IP prefix: 192.168.0.1/32
> Add IP prefix: 192.168.0.0/24
> Lkp IP prefix: 192.168.0.1/32
> Del IP prefix: 192.168.0.0/24
> Lkp IP prefix: 192.168.0.1/32
> Del IP prefix: 192.160.0.0/11
>
> Thread 1 "iplookuptable" received signal SIGSEGV, Segmentation fault.
> odph_iplookup_table_destroy (tbl=tbl@entry=0x7fffd5ed4000) at
> iplookuptable.c:552
> 552                             if (subtree[j].child == 0)
> (gdb) backtrace
> #0  odph_iplookup_table_destroy (tbl=tbl@entry=0x7fffd5ed4000) at
> iplookuptable.c:552
> #1  0x000000000040a062 in test_ip_lookup_table () at iplookuptable.c:137
> #2  main (argc=<optimized out>, argv=<optimized out>) at
> iplookuptable.c:158
>

I am not able to reproduce this issue with 2MB on my system.

/Krishna
Elo, Matias (Nokia - FI/Espoo) March 2, 2017, 9:11 a.m. | #6
> 
> Seems like you are using 2MB page size not 1G and they are not mounted as well. 
>  
> I am not able to reproduce this issue with 2MB on my system.
> 


The debug print is a bit misleading as my system hugepagesize size is 2M. Only one 1G page is actually mounted.

After banging my head to the table long enough I finally rebooted the server and surprise, surprise, everything is working now.

So it seems the only needed change to wrapper file is to increase the number of 2M pages.

-Matias

Patch

diff --git a/test/linux-dpdk/wrapper-script.sh b/test/linux-dpdk/wrapper-script.sh
index c43520f..485c1ba 100755
--- a/test/linux-dpdk/wrapper-script.sh
+++ b/test/linux-dpdk/wrapper-script.sh
@@ -43,21 +43,14 @@  if [ ! -d $HUGEPAGEDIR ]; then
 	sudo mkdir -p $HUGEPAGEDIR
 fi
 echo "Mounting hugetlbfs"
-export SIZE=1G
-export SIZE_KB=1048576
-export RESERVE=1
+export SIZE=2MB
+export SIZE_KB=2048
+export RESERVE=1024
 mount_and_reserve
 res=$?
 if [ $res -ne 0 ]; then
-	export SIZE=2MB
-	export SIZE_KB=2048
-	export RESERVE=256
-	mount_and_reserve
-	res=$?
-	if [ $res -ne 0 ]; then
-		echo "ERROR: can't mount hugepages with any size"
-		exit $res
-	fi
+	echo "ERROR: can't mount hugepages with 2MB size"
+	exit $res
 fi
 echo "running $1!"
 if [ ${1: -3} == ".sh" ]