DPDK patches and discussions
 help / color / mirror / Atom feed
From: Gopakumar Choorakkot Edakkunni <gopakumar.c.e@gmail.com>
To: dev@dpdk.org
Subject: [dpdk-dev] dpdk-2.0.0: crash in ixgbe_recv_scattered_pkts_vec->_recv_raw_pkts_vec->desc_to_olflags_v
Date: Tue, 30 Jun 2015 08:49:32 -0700	[thread overview]
Message-ID: <CABK1yFCHE8VoCxkuJBVw2x1PfzpKn64pkajynO6rW-MiS6NumQ@mail.gmail.com> (raw)

Hi,

I am starting to tryout dpdk-2.0.0 with a simple Rx routine very
similar to the l2fwd example - I am running this on a c3.8xlarge aws
sr-iov enabled vpc instance (inside the vm it uses ixgbevf driver).

Once in every 10 minutes my application crashes in the recieve path.
And whenever I check the crash reason its because it always has three
packets in the burst array (I have provided array size of 32) instead
of the four that it tries to collect in one bunch. And inside
desc_to_olflags_v(), theres the assumption that there are four
packets, and obviously it crashes trying to access the fourth buffer.

With a brief look at the code, I really cant make out how its
guaranteed that we will always have four descriptors fully populated ?
After the first iteration, the loop does break out if (likely(var !=
RTE_IXGBE_DESCS_PER_LOOP)), but how about the very first iteration
where we might not have four ?

Any thoughts will be helpful here, trying to get my app working for
more than 10 minutes :)

#0  0x00000000004c8c58 in desc_to_olflags_v (rx_pkts=0x7f1cb0ff17a0,
descs=<synthetic pointer>)
    at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:173
#1  _recv_raw_pkts_vec (rxq=0x7f1d364fcbc0, rx_pkts=<optimized out>,
nb_pkts=<optimized out>, split_packet=0x7f1cb0ff16d0 "")
    at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:305
#2  0x00000000004c9cea in ixgbe_recv_scattered_pkts_vec
(rx_queue=0x7f1d364fcbc0, rx_pkts=0x7f1cb0ff17a0,
    nb_pkts=<optimized out>) at
/home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:475
#3  0x00000000006b9bd8 in rte_eth_rx_burst (port_id=0 '\000',
queue_id=0, rx_pkts=0x7f1cb0ff17a0, nb_pkts=32)
    at /home/gopa/usr/dpdk/include/rte_ethdev.h:2417

---

(gdb) frame 0
#0  0x00000000004c8c58 in desc_to_olflags_v (rx_pkts=0x7f1cb0ff17a0,
descs=<synthetic pointer>)
    at /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:173
173    /home/gopa/dpdk-2.0.0/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c: No
such file or directory.
(gdb) p rx_pkts[0]
$9 = (struct rte_mbuf *) 0x7f1cf8284640
(gdb) p rx_pkts[1]
$10 = (struct rte_mbuf *) 0x7f1d3991061c
(gdb) p rx_pkts[2]
$11 = (struct rte_mbuf *) 0x7f1d364fc740
(gdb) p rx_pkts[3]
$12 = (struct rte_mbuf *) 0x0
(gdb)

             reply	other threads:[~2015-06-30 15:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 15:49 Gopakumar Choorakkot Edakkunni [this message]
2015-06-30 16:08 ` Bruce Richardson
2015-06-30 16:08 ` Thomas Monjalon
2015-06-30 18:28   ` Gopakumar Choorakkot Edakkunni
2015-07-01  0:50     ` Gopakumar Choorakkot Edakkunni
2015-07-01 11:11       ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABK1yFCHE8VoCxkuJBVw2x1PfzpKn64pkajynO6rW-MiS6NumQ@mail.gmail.com \
    --to=gopakumar.c.e@gmail.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).