Bug 382
Summary: | rte_eth: rx/tx callbacks invoked without lock protection | ||
---|---|---|---|
Product: | DPDK | Reporter: | Linfan (zhongdahulinfan) |
Component: | ethdev | Assignee: | dev |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | thomas, zhongdahulinfan |
Priority: | Normal | ||
Version: | 18.11 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Linfan
2020-01-09 08:52:34 CET
There is no lock protection in the datapath for performance reason. The application must take care of stopping Rx on the devices before unregistering the callbacks. Is it OK for you? On Thu, 09 Jan 2020 07:52:34 +0000 bugzilla@dpdk.org wrote: > https://bugs.dpdk.org/show_bug.cgi?id=382 > > Bug ID: 382 > Summary: rte_eth: rx/tx callbacks invoked without lock > protection > Product: DPDK > Version: 18.11 > Hardware: All > OS: All > Status: UNCONFIRMED > Severity: normal > Priority: Normal > Component: ethdev > Assignee: dev@dpdk.org > Reporter: zhongdahulinfan@163.com > Target Milestone: --- > > Hi, all > I launch my DPDK app, and then use dpdk-pdump to capture wire packets. > When > I stop dpdk-pdump with ctrl+c, my DPDK app crash. Here is the coredump > backtrace: > > ``` dpdk-pdump needs a signal handler to catch control-c and unregister its callback. Hi Stephen, dpdk-pdump has its signal handler: static void signal_handler(int sig_num) { if (sig_num == SIGINT) { printf("\n\nSignal %d received, preparing to exit...\n", sig_num); quit_signal = 1; } } dpdk-pdump wil cleanup pdump resources, including removing callbacks, before it exits. Hi Thomas, Our DPDK application runs online and stopping RX and/or TX is not acceptable. Given that callbacks are allowed to register/unregister dynamically, I think protection mechanism should be considered while calling callbacks. Maybe RCU is tolerable If lock is too expansive? |