From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 3EBBF7E89 for ; Mon, 20 Oct 2014 19:24:28 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 Oct 2014 10:31:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,757,1406617200"; d="scan'208";a="592547937" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 20 Oct 2014 10:31:30 -0700 Received: from irsmsx110.ger.corp.intel.com (163.33.3.25) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Oct 2014 18:31:29 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.21]) by IRSMSX110.ger.corp.intel.com ([169.254.15.199]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 18:31:28 +0100 From: "De Lara Guarch, Pablo" To: Marc Sune , "" Thread-Topic: [dpdk-dev] Memory corruption in librte_ether? Thread-Index: AQHP6k+6pj5I9xloj0yA3IpVjjHt1Zw5QKPQ Date: Mon, 20 Oct 2014 17:31:29 +0000 Message-ID: References: <5441873F.90500@bisdn.de> In-Reply-To: <5441873F.90500@bisdn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Memory corruption in librte_ether? 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: Mon, 20 Oct 2014 17:24:28 -0000 Hi Marc, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marc Sune > Sent: Friday, October 17, 2014 10:17 PM > To: > Subject: [dpdk-dev] Memory corruption in librte_ether? >=20 > Hi all, >=20 > I was rebasing the KNI mempool v4 patch(I have it finalised, but wanted > to check) to the latest master HEAD > (075e064089e1c2b6899db58c69be1a387eb5ffa7) when I ran into problems > with > the current KNI example with em interfaces in a VM. I then switched to > master's head and retried (so without the KNI mempool patch!) with the > *same behaviour*. Behaviour here listed is with master head, so nothing > to do with the patch I am working on. >=20 > The *VM*, emulated with qemu has 4 e1000 interfaces attached to several > bridges. qmeu version 1.1.2 running in debian 7 64bit. With this setup I > get the error: >=20 [...]=20 > Which seems to indicate rte_eth_dev_info_get() is somehow corrupting > memory(?=BF). But I haven't figure out the problem (yet). I suspect of: >=20 > commit fbde27f19ab8f1d386868275bd8c016e693cf073 > Author: Pablo de Lara > Date: Wed Oct 1 10:49:04 2014 +0100 >=20 > ethdev: get default Rx/Tx configuration from dev info >=20 > Many sample apps use duplicated code to set rte_eth_txconf and > rte_eth_rxconf > structures. This patch allows the user to get a default optimal > RX/TX configuration > through rte_eth_dev_info get, and still any parameters may be > tweaked as wished, > before setting up queues. >=20 > Besides, if a NULL pointer is passed to rte_eth_rx_queue_setup or > rte_eth_tx_queue_setup, these functions get internally the default > RX/TX > configuration for the user. >=20 > Signed-off-by: Pablo de Lara > Reviewed-by: Bruce Richardson > Acked-by: David Marchand > [Thomas: split patch] >=20 > commit a30268e9a2d0618902e8cf96b90b27db4fb02d54 > Author: Pablo de Lara > Date: Wed Oct 1 10:49:03 2014 +0100 >=20 > ethdev: reset whole dev info structure before filling >=20 > To guarantee that RX/TX configuration structures are reseted > before modifying them, plus the other dev info fields, > dev info structure is zeroed beforehand. >=20 > Signed-off-by: Pablo de Lara > Acked-by: David Marchand >=20 >=20 > Can anyone confirm it? I just pushed a fix for that problem. Indeed, the dev_info structure was po= lluted,=20 because I was calling the specific dev_info_get function in the PMDs,=20 and not calling rte_eth_dev_info_get in rte_ethdev.c, which means that the dev_info structure was not being reseted.=20 In your case, em PMD does not overwrite the rte_eth_rxconf and=20 rte_eth_txconf structures, and then you find random data in those structure= s. Well spotted and thanks very much for all the details.=20 I would appreciate if you could verify that this patch works for you. Thanks, Pablo >=20 > Marc >=20 > p.s. Has someone managed to run a dpdk app with valgrind?