From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dorgreen1@gmail.com>
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com
 [209.85.215.54]) by dpdk.org (Postfix) with ESMTP id 218953796
 for <dev@dpdk.org>; Mon, 23 Mar 2015 15:24:19 +0100 (CET)
Received: by labe2 with SMTP id e2so60023081lab.3
 for <dev@dpdk.org>; Mon, 23 Mar 2015 07:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:content-type;
 bh=oRCS99xWE8G6jgXI+RGE8xo3yFBXfJyGgevXQwC7YqA=;
 b=Eyj40n5dTZLC8tLBbLwqivWoICItbaoDrx2RkXJe4H2PbHLob579HPq22ZCREvk1Yk
 kjC+altu6xknNEbttVSKZp8LyuVUMpTPXmwj2VChGfxF6ZQQ/9OcnrdUIABkbW5Uz8i4
 m3IbSvsnWQODIHQF35DSIrU35Wieh+GCnHXk2vXg2eqrhHAayCK2vRzkjfAlzXuombV9
 7MJYpCG5JlgRuyhUrCdlo4zFmVJ7AEzyCJA1vhXoFIOig3RPy7P3YcAZ3hNp9QtnaO+r
 4HQ9yqafibDFdnX2ZI6Iz7rUJyEbAzKpxU1b1qL16vUIfhULZtFh0VALpfIA/mRrehIs
 +FWw==
MIME-Version: 1.0
X-Received: by 10.152.44.161 with SMTP id f1mr67440505lam.26.1427120658805;
 Mon, 23 Mar 2015 07:24:18 -0700 (PDT)
Received: by 10.25.31.4 with HTTP; Mon, 23 Mar 2015 07:24:18 -0700 (PDT)
Date: Mon, 23 Mar 2015 16:24:18 +0200
Message-ID: <CAKedurxdjBt5FiCo0J=2V9d4=GEac6cBAxtWuXfwJ4hMX83L9w@mail.gmail.com>
From: Dor Green <dorgreen1@gmail.com>
To: dev@dpdk.org
Content-Type: text/plain; charset=UTF-8
Subject: [dpdk-dev] Packet data out of bounds after rte_eth_rx_burst
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 14:24:19 -0000

I'm running a small app which captures packets on a single lcore and
then passes it to other workers for processing.

Before even sending it to processing, when checking some minor
information in the packet mbuf's data I get a segfault.

This code, for example gets a segfault:

struct rte_mbuf *pkts[PKTS_BURST_SIZE];

for (p = 0; p < portnb; ++p) {
    nbrx = rte_eth_rx_burst(p, 0, pkts, PKTS_BURST_SIZE);

    if (unlikely(nbrx == 0)) {
        continue;
    }

    for (i = 0; likely(i < nbrx); i++) {
        printf("Pkt %c\n", pkts[i]->pkt->data[0]);
        rte_mempool_put(pktmbuf_pool, (void *const)pkts[i]);
    }
}

This doesn't happen on most packets, but when I used packets from a
certain cap it happened often (SSL traffic). In gdb the packet objects
looked like this:
{next = 0x0, data = 0x62132136406a6f6, data_len = 263, nb_segs = 1
'\001', in_port = 0 '\000', pkt_len = 263, vlan_macip = {data = 55111,
f = {l3_len = 327, l2_len = 107, vlan_tci = 0}}, hash = {
    rss = 311317915, fdir = {hash = 21915, id = 4750}, sched =
311317915}} (Invalid)
 {next = 0x0, data = 0x7ffe43d8f640, data_len = 73, nb_segs = 1
'\001', in_port = 0 '\000', pkt_len = 73, vlan_macip = {data = 0, f =
{l3_len = 0, l2_len = 0, vlan_tci = 0}}, hash = {rss = 311317915,
    fdir = {hash = 21915, id = 4750}, sched = 311317915}} (Valid)
{next = 0x0, data = 0x7ffe43d7fa40, data_len = 74, nb_segs = 1 '\001',
in_port = 0 '\000', pkt_len = 74, vlan_macip = {data = 0, f = {l3_len
= 0, l2_len = 0, vlan_tci = 0}}, hash = {rss = 311317915,
    fdir = {hash = 21915, id = 4750}, sched = 311317915}} (Valid)
{next = 0x0, data = 0x7ffe43d7ff80, data_len = 66, nb_segs = 1 '\001',
in_port = 0 '\000', pkt_len = 66, vlan_macip = {data = 0, f = {l3_len
= 0, l2_len = 0, vlan_tci = 0}}, hash = {rss = 311317915,
    fdir = {hash = 21915, id = 4750}, sched = 311317915}} (Valid)
{next = 0x0, data = 0x28153a8e63b3afc4, data_len = 263, nb_segs = 1
'\001', in_port = 0 '\000', pkt_len = 263, vlan_macip = {data = 59535,
f = {l3_len = 143, l2_len = 116, vlan_tci = 0}}, hash = {
    rss = 311317915, fdir = {hash = 21915, id = 4750}, sched =
311317915}} (Invalid)

Note that in the first packet, the length does not match the actual
packet length (it does in the last though). The rest of the packets
are placed in the hugemem range as they should be.

I'm running on Linux 3.2.0-77, the NIC is "10G 2P X520", I have 4 1GB
huge pages.

Any ideas will be appreciated.