From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 75E08A034E for ; Sun, 7 Jun 2020 04:41:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 973081C1A0; Sun, 7 Jun 2020 04:41:47 +0200 (CEST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by dpdk.org (Postfix) with ESMTP id 7C5DC1C19F for ; Sun, 7 Jun 2020 04:41:46 +0200 (CEST) Received: by mail-wr1-f41.google.com with SMTP id j10so13775179wrw.8 for ; Sat, 06 Jun 2020 19:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIQKXoGKJMMTzI1wpCzrPNkyOy1iQIqyzYXP1s4c+2Y=; b=j3pAujmi2pgZ6nV8qK7KVs6WovWzFRKJ8j1KkMO4dYqWgopiwNZbHT80aSvyUB5mYC nX5Xgns8JYFrNqTPbaUJEm0tCdW/ftW2fz06GU0qJA4QlwTsqcVGBWQQYmjV9w8FdePh gv0zoqfDpLqcfhRa3E6UTUpCr9nUoh/OPrsOUILGpmw+csC/dOETEu8GJjAH4izZWHCO 98PY0iyHWfej6q0jN7zU+LDCs8g/OfS8CoZ7Qds5x4b4sEmnyjw4XAkkb7z1AcTb2AQ6 jEWVp70DxTrMDPm52S4F05K9H893v6iwPMSPTRWblKanW4xhixZ5jEUJUlD8STLtHsIw 8spg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pIQKXoGKJMMTzI1wpCzrPNkyOy1iQIqyzYXP1s4c+2Y=; b=plAOIlxUAalE/ZpgNQuqXPhBJ9nofgWZ2sgzFCFwH7BEqDQipsoyCtMkbPFuGsfGJR NufGpOjWNdRshQ3Rs25kjjBuXZTEDLWQ5HmomrqDcKY0uDR9lMyIQ34a3Ga1IPO1Vu9N 8rbtOCu1/M6A65gPcH6tOBzbRr3+CHeP4xnBLHR7U+sbJ1KNUxdLUUAQc4flzs6oy1Bh QglguPjpohqJRSvotd0nlhc9UbWhUnptLomIJ4sQPrLvj11/3J+vsa3moZ0KIOVkvcnl Mh1+THV/A9myjaAHyDXQeWuU4u+NiEBpgafmcCABWb8ulm7pgL/kBm6PLlx/9KsJVHeB FI1A== X-Gm-Message-State: AOAM5314sauerEX1Ko/PnPu4l3/2OEHlCs1DaLxC6lXAlS4C5Xzv/R4s 8qPqQa3wjfihydR61dGVrk1EyANkxMHi79Sk22uz5Oo7 X-Google-Smtp-Source: ABdhPJzpb5KSfK3HhzHmioVmLuZkr4PcEWeIULiJCW03ILBmUG0qpU33Hz+n5h6G2uXd9sxx0/RjKyzaAf2SvxvsYUU= X-Received: by 2002:a5d:5489:: with SMTP id h9mr16411808wrv.125.1591497706022; Sat, 06 Jun 2020 19:41:46 -0700 (PDT) MIME-Version: 1.0 References: <504fcb6e5a12a03035e7b55507e7c279@therouter.net> <20200601091729.03ea9e50@hermes.lan> <7DA537F2-9887-4B0A-9249-064736E8A9AD@therouter.net> In-Reply-To: <7DA537F2-9887-4B0A-9249-064736E8A9AD@therouter.net> From: Cliff Burdick Date: Sat, 6 Jun 2020 19:41:35 -0700 Message-ID: To: Alex Kiselev Cc: Stephen Hemminger , users Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] segmention fault while accessing mbuf X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" I can't tell from your code, but you assigned nb_rx to the number of packets received, but then used vec_size, which might be larger. Does this happen if you use nb_rx in your loops? On Sat, Jun 6, 2020 at 5:59 AM Alex Kiselev wrote: > > > > 1 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3., =D0=B2 19:17, Stephen Hemminge= r > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): > > > > On Mon, 01 Jun 2020 15:24:25 +0200 > > Alex Kiselev wrote: > > > >> Hello, > >> > >> I've got a segmentation fault error in my data plane path. > >> I am pretty sure the code where the segfault happened is ok, > >> so my guess is that I somehow received a corrupted mbuf. > >> How could I troubleshoot this? Is there any way? > >> Is it possible that other threads of the application > >> corrupted that mbuf? > >> > >> I would really appriciate any advice. > >> Thanks. > >> > >> DPDK 18.11.3 > >> NIC: 82599ES > >> > >> Code: > >> > >> nb_rx =3D rte_eth_rx_burst(port_id, queue_id, pkts_burst, > >> MAX_PKT_BURST); > >> > >> ... > >> > >> for (i=3D0; i < vec_size; i++) { > >> rte_prefetch0(rte_pktmbuf_mtod(m_v[i], void *)); > >> > >> for (i=3D0; i < vec_size; i++) { > >> m =3D m_v[i]; > >> eth_hdr =3D rte_pktmbuf_mtod(m, struct ether_hdr *); > >> eth_type =3D rte_be_to_cpu_16(eth_hdr->ether_type); <= --- > >> Segmentation fault > >> ... > >> > >> #0 rte_arch_bswap16 (_x=3D >> at address 0x4d80000000053010>) > > > > Build with as many of the debug options turned on in the DPDK config, > > and build with EXTRA_CFLAGS of -g. > > Could using an incorrect (a very big one) value of mbuf pkt_len and > data_len while transmitting cause mbuf corruption and following > segmentation fault on rx? >