From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31]) by dpdk.org (Postfix) with ESMTP id B75A77E80 for ; Tue, 21 Oct 2014 10:03:55 +0200 (CEST) Received: from [192.168.1.43] (42.Red-79-146-253.dynamicIP.rima-tde.net [79.146.253.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.bisdn.de (Postfix) with ESMTPSA id DC115A2DA9; Tue, 21 Oct 2014 10:12:09 +0200 (CEST) Message-ID: <54461577.6080005@bisdn.de> Date: Tue, 21 Oct 2014 10:12:39 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: "De Lara Guarch, Pablo" References: <5441873F.90500@bisdn.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" 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: Tue, 21 Oct 2014 08:03:56 -0000 Pablo, I've only tried with the kni-autotest but it seems to work fine. Thanks! Btw, at least in my development VM the kni-autotest in the current head (455d09e i40e: generic filter control), but also in v1.7.1, fails: RTE>>kni_autotest master lcore: 0 count: 2 PMD: eth_em_rx_queue_setup(): sw_ring=0x7f27ab4e8100 hw_ring=0x7f27aa600000 dma_addr=0x36e00000 PMD: eth_em_tx_queue_setup(): sw_ring=0x7f27ab4e6000 hw_ring=0x7f27aa610000 dma_addr=0x36e10000 PMD: eth_em_start(): << KNI: pci: 00:06:00 8086:100e KNI: Invalid KNI request operation. KNI: Invalid kni info. KNI: The KNI request operationhas already registered. Change MTU of port 0 to 1450 Change MTU of port 0 to 1450 successfully. KNI: Invalid kni info. The ingress/egress number should not be less than 100 Test Failed RTE>> Maybe it is simply a lack of resources in the qemu VM. Saludos marc On 20/10/14 19:31, De Lara Guarch, Pablo wrote: > 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? >> >> Hi all, >> >> 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. >> >> 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: >> > [...] >> Which seems to indicate rte_eth_dev_info_get() is somehow corrupting >> memory(?¿). But I haven't figure out the problem (yet). I suspect of: >> >> commit fbde27f19ab8f1d386868275bd8c016e693cf073 >> Author: Pablo de Lara >> Date: Wed Oct 1 10:49:04 2014 +0100 >> >> ethdev: get default Rx/Tx configuration from dev info >> >> 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. >> >> 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. >> >> Signed-off-by: Pablo de Lara >> Reviewed-by: Bruce Richardson >> Acked-by: David Marchand >> [Thomas: split patch] >> >> commit a30268e9a2d0618902e8cf96b90b27db4fb02d54 >> Author: Pablo de Lara >> Date: Wed Oct 1 10:49:03 2014 +0100 >> >> ethdev: reset whole dev info structure before filling >> >> To guarantee that RX/TX configuration structures are reseted >> before modifying them, plus the other dev info fields, >> dev info structure is zeroed beforehand. >> >> Signed-off-by: Pablo de Lara >> Acked-by: David Marchand >> >> >> Can anyone confirm it? > I just pushed a fix for that problem. Indeed, the dev_info structure was polluted, > because I was calling the specific dev_info_get function in the PMDs, > and not calling rte_eth_dev_info_get in rte_ethdev.c, which means that > the dev_info structure was not being reseted. > In your case, em PMD does not overwrite the rte_eth_rxconf and > rte_eth_txconf structures, and then you find random data in those structures. > Well spotted and thanks very much for all the details. > I would appreciate if you could verify that this patch works for you. > > Thanks, > Pablo >> Marc >> >> p.s. Has someone managed to run a dpdk app with valgrind?