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 at dpdk.org] On Behalf Of Marc Sune >> Sent: Friday, October 17, 2014 10:17 PM >> To: <dev at dpdk.org> >> 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 <pablo.de.lara.guarch at intel.com> >> 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 <pablo.de.lara.guarch at intel.com> >> Reviewed-by: Bruce Richardson <bruce.richardson at intel.com> >> Acked-by: David Marchand <david.marchand at 6wind.com> >> [Thomas: split patch] >> >> commit a30268e9a2d0618902e8cf96b90b27db4fb02d54 >> Author: Pablo de Lara <pablo.de.lara.guarch at intel.com> >> 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 <pablo.de.lara.guarch at intel.com> >> Acked-by: David Marchand <david.marchand at 6wind.com> >> >> >> 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?
