From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by dpdk.org (Postfix) with ESMTP id B8A895A8A for ; Fri, 20 Mar 2015 19:26:03 +0100 (CET) Received: by wetk59 with SMTP id k59so88548627wet.3 for ; Fri, 20 Mar 2015 11:26:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pWcYGRwCUHbyz7ayue4CiwxNV3tEchs6kQdPYTSugOo=; b=ExO3P+1f7BB34yUALwfxWk84SVbC66Wb6YfbTXWqb/NoQ+zgxfnb/q8WX8/0VGzAQw x4ufOsMhCEKhOpdEaWxbhEeiE5AphGgFp/I4g75znFKDSkA3zAnwoI48+0nNXe4oER6m Ck8K87kMEQ0bCVcrcdgIJyZtFFGLebAQzIYLUr6n9XN2WjQ4Vf9rp6MT+yDLYIQFM4EW 2dnJph+CGlBpDibZyKLsRnwz18lWF33V1MbhPDQZv0N7uFeHpF0KrIDDCQk60Yq+Rswd Clgjk0ELBGwC3ltbet2b67/isxJa1IFcQUi1S9IIDygkOdCmFvmgFmT4qjdtbv24CLPJ fGMg== X-Gm-Message-State: ALoCoQmyOzomM2DuDqAT998nEJgAqd9j3opphRHZ7Z8o+uue6GxFNMCU5Iyj5n8QpXj6//q4Q6xV MIME-Version: 1.0 X-Received: by 10.180.96.37 with SMTP id dp5mr20149756wib.41.1426875963485; Fri, 20 Mar 2015 11:26:03 -0700 (PDT) Received: by 10.194.179.195 with HTTP; Fri, 20 Mar 2015 11:26:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Mar 2015 13:26:03 -0500 Message-ID: From: Jay Rolette To: bford@vossen.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: DPDK Subject: Re: [dpdk-dev] soft lockup calling receive burst X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:26:04 -0000 On Fri, Mar 20, 2015 at 12:53 PM, Joseph Vossen wrote: > hello, > > I am working on a dpdk-based app using version 1.6 under RH7.3. Under > varying traffic loads, I will intermittently notice a kernel soft lockup > and the RIP provided by the kernel always points to the same MOV > instruction in rte_ethdev.h (line #1982). The stack trace looks like: > > > dev = &rte_eth_devices[port_id]; > return > (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id], rx_pkts, nb_pkts); > > > 473176: 0f b7 15 a7 68 38 00 movzwl > 0x3868a7(%rip),%edx # 7f9a24 rte_eth_rx_burst(): > 47317d: 0f b6 31 movzbl > (%rcx),%esi > 473180: 48 89 f0 mov > %rsi,%rax > 473183: 0f b6 71 01 movzbl > 0x1(%rcx),%esi > 473187: 48 c1 e0 06 shl $0x6,%rax > 47318b: 48 8b b8 70 ed 83 00 mov > 0x83ed70(%rax),%rdi > ----> 473192: 48 8b 0f mov > (%rdi),%rcx > 473195: 48 8b 3c f1 mov > (%rcx,%rsi,8),%rdi > 473199: 4c 89 ee mov > %r13,%rsi > 47319c: ff 90 60 ed 83 00 callq > *0x83ed60(%rax) > > > has any one else seen something like this? > > thanks I haven't seen that, but there's a soft-lockup in KNI in DPDK 1.6. Here's what I posted about that one a few weeks ago: Found the problem. No patch to submit since it's already fixed in later versions of DPDK, but thought I'd follow up with the details since I'm sure we aren't the only ones trying to use bleeding-edge versions of DPDK... In kni_net_rx_normal(), it was calling netif_receive_skb() instead of netif_rx(). The source for netif_receive_skb() point out that it should only be called from soft-irq context, which isn't the case for KNI. As typical, simple fix once you track it down. Yao-Po Wang's fix: commit 41a6ebded53982107c1adfc0652d6cc1375a7db9. Jay