Re: [dpdk-dev] [PATCH 2/2] event/sw: use dynamically-sized IQs

["Van Haaren, Harry" <harry.van.haaren@intel.com>]

> From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com]
> Sent: Monday, January 8, 2018 3:32 PM
> To: Eads, Gage <gage.eads@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; jerin.jacob@caviumnetworks.com;
> santosh.shukla@caviumnetworks.com
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 2/2] event/sw: use dynamically-sized IQs
> 
> On Wed, Nov 29, 2017 at 09:08:34PM -0600, Gage Eads wrote:
> > This commit introduces dynamically-sized IQs, by switching the underlying
> > data structure from a fixed-size ring to a linked list of queue 'chunks.'

<snip>

> Sw eventdev crashes when used alongside Rx adapter. The crash happens when
> pumping traffic at > 1.4mpps. This commit seems responsible for this.
> 
> 
> Apply the following Rx adapter patch
> http://dpdk.org/dev/patchwork/patch/31977/
> Command used:
> ./build/eventdev_pipeline_sw_pmd -c 0xfffff8 --vdev="event_sw" -- -r0x800
> -t0x100 -w F000 -e 0x10

Applied the patch to current master, recompiled; cannot reproduce here..

Is it 100% reproducible and "instant" or can it take some time to occur there?


> Backtrace:
> 
> Thread 4 "lcore-slave-4" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xffffb6c8f040 (LWP 25291)]
> 0x0000aaaaaadcc0d4 in iq_dequeue_burst (count=48, ev=0xffffb6c8dd38,
> iq=0xffff9f764720, sw=0xffff9f332600) at
> /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:142
> 142 ev[total++] = current->events[index++];

Could we get the output of (gdb) info locals?



> (gdb) bt
> #0  0x0000aaaaaadcc0d4 in iq_dequeue_burst (count=48, ev=0xffffb6c8dd38,
> iq=0xffff9f764720, sw=0xffff9f332600) at
> /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:142
> #1  sw_schedule_atomic_to_cq (sw=0xffff9f332600, qid=0xffff9f764700,
> iq_num=0,
> count=48) at
> /root/clean/rebase/dpdk-next-
> eventdev/drivers/event/sw/sw_evdev_scheduler.c:74
> #2  0x0000aaaaaadcdc44 in sw_schedule_qid_to_cq (sw=0xffff9f332600) at
> /root/clean/rebase/dpdk-next-
> eventdev/drivers/event/sw/sw_evdev_scheduler.c:262
> #3  0x0000aaaaaadd069c in sw_event_schedule (dev=0xaaaaaafbd200
> <rte_event_devices>) at
> /root/clean/rebase/dpdk-next-
> eventdev/drivers/event/sw/sw_evdev_scheduler.c:564
> #4  0x0000aaaaaadca008 in sw_sched_service_func (args=0xaaaaaafbd200
> <rte_event_devices>) at
> /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/sw_evdev.c:767
> #5  0x0000aaaaaab54740 in rte_service_runner_do_callback (s=0xffff9fffdf80,
> cs=0xffff9ffef900, service_idx=0) at
> /root/clean/rebase/dpdk-next-
> eventdev/lib/librte_eal/common/rte_service.c:349
> #6  0x0000aaaaaab54868 in service_run (i=0, cs=0xffff9ffef900,
> service_mask=18446744073709551615) at
> /root/clean/rebase/dpdk-next-
> eventdev/lib/librte_eal/common/rte_service.c:376
> #7  0x0000aaaaaab54954 in rte_service_run_iter_on_app_lcore (id=0,
> serialize_mt_unsafe=1) at
> /root/clean/rebase/dpdk-next-
> eventdev/lib/librte_eal/common/rte_service.c:405
> #8  0x0000aaaaaaaef04c in schedule_devices (lcore_id=4) at
> /root/clean/rebase/dpdk-next-
> eventdev/examples/eventdev_pipeline_sw_pmd/main.c:223
> #9  0x0000aaaaaaaef234 in worker (arg=0xffff9f331d80) at
> /root/clean/rebase/dpdk-next-
> eventdev/examples/eventdev_pipeline_sw_pmd/main.c:274
> #10 0x0000aaaaaab4382c in eal_thread_loop (arg=0x0) at
> /root/clean/rebase/dpdk-next-
> eventdev/lib/librte_eal/linuxapp/eal/eal_thread.c:182
> #11 0x0000ffffb7e46d64 in start_thread () from /usr/lib/libpthread.so.0
> #12 0x0000ffffb7da8bbc in thread_start () from /usr/lib/libc.so.6
> 
> Segfault seems to happen in sw_event_schedule and only happens under high
> traffic load.

I've added -n 0 to the command line allowing it to run forever,
and after ~2 mins its still happily forwarding pkts at ~10G line rate here.


> Thanks,
> Pavan

Thanks for reporting - I'm afraid I'll have to ask a few questions to identify why I can't reproduce here before I can dig in and identify a fix.

Anything special about the system that it is on?
What traffic pattern is being sent to the app?

Thanks


<snip>