From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by dpdk.org (Postfix) with ESMTP id C27705682 for ; Sat, 20 Aug 2016 03:30:18 +0200 (CEST) Received: by mail-pa0-f50.google.com with SMTP id ti13so20679700pac.0 for ; Fri, 19 Aug 2016 18:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=r31MMxlQikzEMctJrtF8q6bxC+6OXKAyCcUwCL52VcY=; b=yPtaag5VyZaKuAOrbiNf5tDe9nZW1jE2RzMwdZnx0MvPGnsfFE6UYLQXdxFyKTVdMv QNG9Ezndootv5SHwkgHURVo/fnnJTi4j7k50Yk0XH0Tq9ryhW1DYgFFIfquBrsGBKbay KSCxfnxewd+20VrBQIrLa4xhui4WqP26jrmN6KsRis0TWqRvWHu0ZsqpeEMgY+M04cvQ slsJ62/9nTiii6Nn+PWcxvf8gMS3wLaEMCZdslxWdmLk7IQavauF3eRntHVpGnG5sCuA w8A7Nmg/lzjJbIeG2YGuaPJsPTgefhkIBxB4XUastuNJDxCBmnuxf9qU6cpmWKCsMOo+ lrGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=r31MMxlQikzEMctJrtF8q6bxC+6OXKAyCcUwCL52VcY=; b=e0XDdOeE/YNAoC4Bv7n3W0xXZ+YXqG1GkcrFmSl1x5KNj77f/RcK5Up4qnVaymqgS5 3DsGc6ch8mPtbkFieWGUnNj0VrTtJ/Jd5KQbrtxZyHtLazpOaZTEMMrS1lTYl+AWGjvG 7Byg6V5pMxVSfqqV2w9VujFHKLK+KW4utKP5ky3jOx+g0L7aYMaFvtGgxZSfMuUL31IR KC448koADpXcwZ+22x13PivAzLVgf+lWhFIJK/mh9XyCPNLaqI64LJYVVXcnPkn/qR31 Mg2tazRkc28ZHBkyKaTrcDFXzwY4fupKt+ifEekYYSbRWqSxtO35u3evPaG4vHbTHD3j hOPw== X-Gm-Message-State: AEkoouu/DAHgeXYZkyUcuOXwJ87/Il4qtk1n5/QZlHXNpKydeAqnbPPNBcu6cuaLRVsuug== X-Received: by 10.66.253.101 with SMTP id zz5mr19052223pac.32.1471656618026; Fri, 19 Aug 2016 18:30:18 -0700 (PDT) Received: from xeon-e3 (static-50-53-69-251.bvtn.or.frontiernet.net. [50.53.69.251]) by smtp.gmail.com with ESMTPSA id t7sm14315502paz.21.2016.08.19.18.30.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Aug 2016 18:30:17 -0700 (PDT) Date: Fri, 19 Aug 2016 18:30:29 -0700 From: Stephen Hemminger To: Zhongming Qu Cc: users@dpdk.org Message-ID: <20160819183029.6deb8ebd@xeon-e3> In-Reply-To: References: <20160819140350.70fbc49e@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] running multiple independent dpdk applications randomly locks up machines X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 01:30:19 -0000 On Fri, 19 Aug 2016 18:19:21 -0700 Zhongming Qu 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.