[dpdk-users] running multiple independent dpdk applications randomly locks up machines

Stephen Hemminger stephen at networkplumber.org
Sat Aug 20 03:30:29 CEST 2016

On Fri, 19 Aug 2016 18:19:21 -0700
Zhongming Qu <zhongming at luminatewireless.com> wrote:

> Thanks!
> I did use a hard coded queue_id of 0 when initializing the rx/tx queues,
> i.e., rte_eth_rx/tx_queue_setup(). So that is a problem to solve. Will fix
> that and try again.
> When A and B run at the same time, this lockup problem can be explained by
> the conflicting queue usage. But the lockup happens even in the use case
> where only one dpdk process is running. That is, A and B take turns to run
> but do not run at the same time.
> Thanks for pointing out an alternative approach. That sounds really
> promising. A concern came up when that idea was talked over: What would
> happen if the primary process dies? Would all the secondary processes
> eventually go awry at some point? Would `--proc-type auto` solve this
> problem?

I haven't actually used primary/secondary model, but the recommendation
is that the primary process does nothing (or is a watchdog) so it would
be pretty much impossible to crash unless killed by malicious entity.

All the packet logic would be in the secondary.

More information about the users mailing list