Re: [dpdk-dev] [PATCH v2 0/2] add inline protocol support

[Nelio Laranjeiro <nelio.laranjeiro@6wind.com>]

On Wed, Nov 22, 2017 at 08:43:29PM +0530, Anoob wrote:
>    Hi Nelio,
> 
>    The issue is probably because of a different patch titled, "[PATCH 2/3]
>    crypto: fix pedentic compilation errors". I was able to reproduce the
>    issue with that.
> 
>    Hope this helps.
> 
>    Thanks,
>    Anoob

Hi Anoob,

Indeed, and I am the author for this one, I've tested your series on top
of the it by replacing the RTE_STD_C11 by __extentsion__ which fixes the
pedantic compilation also, I don't have anymore the segfault.

Thanks and sorry for this,

>    On 11/22/2017 06:35 PM, Nelio Laranjeiro wrote:
> 
>  On Wed, Nov 22, 2017 at 06:25:12PM +0530, Anoob wrote:
> 
>  Hi Nelio,
> 
>  Which mode was attempted when you got the crash? Is it with inline-protocol?
> 
>  Hi Annoob,
> 
>  Yes, MLX5 ConnectX-4 Lx INNOVA is an inline crypto NIC.
> 
> 
>  Thanks,
> 
>  Anoob
> 
> 
>  On 11/22/2017 05:51 PM, Nelio Laranjeiro wrote:
> 
>  Hi Anoob,
> 
>  I am facing a segfault in ipsec-secgw with this series when using MLX5
>  PMD, maybe you can help here, see the following gdb backtrace.
> 
>    Thread 1 "ipsec-secgw" received signal SIGSEGV, Segmentation fault.
>    0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>    378             sym_op->sec_session = sess;
>    (gdb) bt
>    #0  0x00005555555b5123 in __rte_security_attach_session (sym_op=0x0, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:378
>    #1  0x00005555555b5178 in rte_security_attach_session (op=0x7fffe8a90008, sess=0x7ffef7edb540) at /root/dpdk/x86_64-native-linuxapp-gcc/include/rte_security.h:414
>    #2  0x00005555555b6389 in ipsec_enqueue (xform_func=0x5555555b7961 <esp_inbound>, ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, sas=0x7fffffffd830,
>        nb_pkts=1) at /root/dpdk/examples/ipsec-secgw/ipsec.c:449
>    #3  0x00005555555b68f5 in ipsec_inbound (ctx=0x555556003a00 <lcore_conf+1689984>, pkts=0x7fffffffdaf0, nb_pkts=1, len=32) at /root/dpdk/examples/ipsec-secgw/ipsec.c:542
>    #4  0x00005555555c3713 in process_pkts_inbound (ipsec_ctx=0x555556003a00 <lcore_conf+1689984>, traffic=0x7fffffffd8f0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:465
>    #5  0x00005555555c42eb in process_pkts (qconf=0x555556001480 <lcore_conf+1680384>, pkts=0x7fffffffe830, nb_pkts=1 '\001', portid=0)
>        at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:699
>    #6  0x00005555555c47eb in main_loop (dummy=0x0) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:792
>    #7  0x00005555556301c5 in rte_eal_mp_remote_launch (f=0x5555555c43e8 <main_loop>, arg=0x0, call_master=CALL_MASTER) at /root/dpdk/lib/librte_eal/common/eal_common_launch.c:91
>    #8  0x00005555555c65a3 in main (argc=8, argv=0x7fffffffeb18) at /root/dpdk/examples/ipsec-secgw/ipsec-secgw.c:1608
> 
>  Thanks,

-- 
Nélio Laranjeiro
6WIND