DPDK patches and discussions
 help / color / mirror / Atom feed
From: Marc Sune <marc.sune@bisdn.de>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "<dev@dpdk.org>" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Memory corruption in librte_ether?
Date: Tue, 21 Oct 2014 10:12:39 +0200	[thread overview]
Message-ID: <54461577.6080005@bisdn.de> (raw)
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8972262DBA9@IRSMSX108.ger.corp.intel.com>

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: <dev@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@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@intel.com>
>>       Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
>>       Acked-by: David Marchand <david.marchand@6wind.com>
>>       [Thomas: split patch]
>>
>> commit a30268e9a2d0618902e8cf96b90b27db4fb02d54
>> Author: Pablo de Lara <pablo.de.lara.guarch@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@intel.com>
>>       Acked-by: David Marchand <david.marchand@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?

      reply	other threads:[~2014-10-21  8:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 21:16 Marc Sune
2014-10-20 17:31 ` De Lara Guarch, Pablo
2014-10-21  8:12   ` Marc Sune [this message]

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=54461577.6080005@bisdn.de \
    --to=marc.sune@bisdn.de \
    --cc=dev@dpdk.org \
    --cc=pablo.de.lara.guarch@intel.com \
    /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).