From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 800475424 for ; Thu, 22 Jan 2015 15:05:45 +0100 (CET) Received: by mail-wg0-f43.google.com with SMTP id y19so1933626wgg.2 for ; Thu, 22 Jan 2015 06:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=66d2eV04wHQly29l8u3KhK5SQifa1qY1mCef7UKpQmY=; b=G/eSdBtMTtvZm1QceSEO/xejNecKWGnIlOgi4LPuE/9GO9N2P1I8ahG4kfA/79+Gjm A8uXw6ugtk31WgO2dQVgA6loUUOQ01ZG464oZUfXZvWrPSpOqKkZYWgcTQ1qucJv6ez/ I93GBV3eic4IgRldQythBc+yHb74mjJkirMBqvhTkv3kHPh73MqM8k9sGxgPUttvWAu9 UoEIeOk5IOEcIvCyuJmQuSM5HL42lXeC3rc4tllH02/Wj//qfqWIvOkp6AQuHVR+EBGf AlROLh1saP5kyKyAXGqaaP+w/onA5ghM0yl0g31CIADHKSnZpxEkVWlc6XPHnTHc5XBy eiDg== MIME-Version: 1.0 X-Received: by 10.194.187.235 with SMTP id fv11mr3588779wjc.16.1421935545359; Thu, 22 Jan 2015 06:05:45 -0800 (PST) Received: by 10.194.2.10 with HTTP; Thu, 22 Jan 2015 06:05:45 -0800 (PST) In-Reply-To: <20150121134921.GA2592@bricha3-MOBL3> References: <54BCDBF1.8020909@allegro-packets.com> <54BE3047.9060909@allegro-packets.com> <20150121134921.GA2592@bricha3-MOBL3> Date: Thu, 22 Jan 2015 19:35:45 +0530 Message-ID: From: Prashant Upadhyaya To: Bruce Richardson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Segmentation fault in ixgbe_rxtx_vec.c:444 with 1.8.0 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: Thu, 22 Jan 2015 14:05:45 -0000 On Wed, Jan 21, 2015 at 7:19 PM, Bruce Richardson < bruce.richardson@intel.com> wrote: > On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote: > > Hi again, > > > > I did some further testing and it seems like this issue is linked to > > jumbo frames. I think a similar issue has already been reported by > > Prashant Upadhyaya with the subject 'Packet Rx issue with DPDK1.8'. > > In our application we use the following rxmode port configuration: > > > > .mq_mode = ETH_MQ_RX_RSS, > > .split_hdr_size = 0, > > .header_split = 0, > > .hw_ip_checksum = 1, > > .hw_vlan_filter = 0, > > .jumbo_frame = 1, > > .hw_strip_crc = 1, > > .max_rx_pkt_len = 9000, > > > > and the mbuf size is calculated like the following: > > > > (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM) > > > > This works fine with DPDK 1.7 and jumbo frames are split into buffer > > chains and can be forwarded on another port without a problem. > > With DPDK 1.8 and the default configuration (CONFIG_RTE_IXGBE_INC_VECTOR > > enabled) the application sometimes crashes like described in my first > > mail and sometimes packet receiving stops with subsequently arriving > > packets counted as rx errors. When CONFIG_RTE_IXGBE_INC_VECTOR is > > disabled the packet processing also comes to a halt as soon as jumbo > > frames arrive with a the slightly different effect that now > > rte_eth_tx_burst refuses to send any previously received packets. > > > > Is there anything special to consider regarding jumbo frames when moving > > from DPDK 1.7 to 1.8 that we might have missed? > > > > Martin > > > > > > > > On 19.01.15 11:26, Martin Weiser wrote: > > > Hi everybody, > > > > > > we quite recently updated one of our applications to DPDK 1.8.0 and are > > > now seeing a segmentation fault in ixgbe_rxtx_vec.c:444 after a few > minutes. > > > I just did some quick debugging and I only have a very limited > > > understanding of the code in question but it seems that the 'continue' > > > in line 445 without increasing 'buf_idx' might cause the problem. In > one > > > debugging session when the crash occurred the value of 'buf_idx' was 2 > > > and the value of 'pkt_idx' was 8965. > > > Any help with this issue would be greatly appreciated. If you need any > > > further information just let me know. > > > > > > Martin > > > > > > > > > Hi Martin, Prashant, > > I've managed to reproduce the issue here and had a look at it. Could you > both perhaps try the proposed change below and see if it fixes the problem > for > you and gives you a working system? If so, I'll submit this as a patch fix > officially - or go back to the drawing board, if not. :-) > > diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > index b54cb19..dfaccee 100644 > --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c > @@ -402,10 +402,10 @@ reassemble_packets(struct igb_rx_queue *rxq, struct > rte_mbuf **rx_bufs, > struct rte_mbuf *pkts[RTE_IXGBE_VPMD_RX_BURST]; /*finished pkts*/ > struct rte_mbuf *start = rxq->pkt_first_seg; > struct rte_mbuf *end = rxq->pkt_last_seg; > - unsigned pkt_idx = 0, buf_idx = 0; > + unsigned pkt_idx, buf_idx; > > > - while (buf_idx < nb_bufs) { > + for (buf_idx = 0, pkt_idx = 0; buf_idx < nb_bufs; buf_idx++) { > if (end != NULL) { > /* processing a split packet */ > end->next = rx_bufs[buf_idx]; > @@ -448,7 +448,6 @@ reassemble_packets(struct igb_rx_queue *rxq, struct > rte_mbuf **rx_bufs, > rx_bufs[buf_idx]->data_len += rxq->crc_len; > rx_bufs[buf_idx]->pkt_len += rxq->crc_len; > } > - buf_idx++; > } > > /* save the partial packet for next time */ > > > Regards, > /Bruce > > Hi Bruce, I am afraid your patch did not work for me. In my case I am not trying to receive jumbo frames but normal frames. They are not received at my application. Further, your patched function is not getting stimulated in my usecase. Regards -Prashant