From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 929A1B363 for ; Wed, 16 Jul 2014 15:22:03 +0200 (CEST) Received: by mail-wg0-f43.google.com with SMTP id l18so905868wgh.26 for ; Wed, 16 Jul 2014 06:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NRA7woosNXdR5oV6r+f+sZ4cE2EZjG4NCAa/a2gN+hY=; b=WowXx+dsqvi8KwiY6ABTEOag2chbIe24ILXTTIeMqjpDzQtAfNveaIXkUBr7fFZ5gv 25Onr2/LxDF8y3bqdDj8JbrySovcFNHk9DS5l3YkDaUd01ISFnKJqoRUEsdmvnTl6pms yYQuGiJMOjIP/AgLguJRnPmeE6M0RSvJXkfVa3TwBjFVtpZ0lct8cIgjxBln1UDY5faf NBvDZWEXek1225CI5h3LSEp9AGepU7+6eTVyBlXFhJp8TxIhkEAEXj52w6fzof7nI7sf /xoevRXmTkXqoVqHDVKFTzKkCyzjrwuV4MVbLlFeQq7bdPlI4QtH5w1NuHqx6n+l5Js6 2o3A== MIME-Version: 1.0 X-Received: by 10.195.13.79 with SMTP id ew15mr34295458wjd.19.1405516974751; Wed, 16 Jul 2014 06:22:54 -0700 (PDT) Received: by 10.194.139.167 with HTTP; Wed, 16 Jul 2014 06:22:54 -0700 (PDT) In-Reply-To: References: <1912860.PvCxTjHaVZ@xps13> <53C66DB2.4040605@6wind.com> Date: Wed, 16 Jul 2014 16:22:54 +0300 Message-ID: From: Helmut Sim To: Olivier MATZ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] phantom old packets received in new mbuf 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: Wed, 16 Jul 2014 13:22:04 -0000 The CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG and CONFIG_RTE_LIBRTE_MBUF_DEBUG didn't provide any input, so I also added the CONFIG_RTE_LIBRTE_ETHDEV_DEBUG and CONFIG_RTE_LIBRTE_IGB_PMD. below is a sample log showing the problem, though I don't see any clue in the logs. in this case pkt 58509 is placed at the place of pkt 58637... I also noted that the diff between the two packets is 128, and this is the case in most of the cases where it happens... the rx_id of the phantom pkt (58509) is 141 (port_id=0 queue_id=0 rx_id=141 staterr=0x3 pkt_len=146) .....still digging port_id=0 queue_id=0 rx_id=264 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=265 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=266 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=267 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=268 nb_hold=4 nb_rx=4 IM_LOG_VFLOWCOM: input: START_10 58632 IM_LOG_VFLOWCOM: input: START_10 58633 IM_LOG_VFLOWCOM: input: START_10 58634 IM_LOG_VFLOWCOM: input: START_10 58635 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=268 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=269 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=270 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=271 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=272 nb_hold=4 nb_rx=4 IM_LOG_VFLOWCOM: input: START_10 58636 IM_LOG_VFLOWCOM: input: START_10 58509 IM_LOG_VFLOWCOM: wrong pkt number arrived from burst 4, expected 58637 but got 58509 IM_LOG_VFLOWCOM: input: START_10 58638 IM_LOG_VFLOWCOM: input: START_10 58639 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=272 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=273 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=274 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_id=275 staterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=276 nb_hold=4 nb_rx=4 IM_LOG_VFLOWCOM: input: START_10 58640 IM_LOG_VFLOWCOM: input: START_10 58641 IM_LOG_VFLOWCOM: input: START_10 58642 IM_LOG_VFLOWCOM: input: START_10 58643 On Wed, Jul 16, 2014 at 3:36 PM, Helmut Sim wrote: > I will try it though I hope the amount of logs won't affect the result. > while analyzing the wireshark captures I noted that the packet i supposed > to capture arrives in a short time after the one before. > for example, here is a time between the consecutive transmitted packets: > 0.000050000 PKT 12201 > 0.000050000 PKT 12202 > 0.000050000 PKT 12203 > 0.000050000 PKT 12204 > 0.000050000 PKT 12205 > 0.000050000 PKT 12206 > 0.000020000 PKT 12207 ==> though this one was received at the app as "PKT > 12202" > 0.000050000 PKT 12208 > > note that the problematic case was transmitted in a very short time after > its previous one. this is also the case in other problematic cases. > > is there any way to configure ethernet IFG (Interf Frame Gap)? > > Thanks, > > > On Wed, Jul 16, 2014 at 3:18 PM, Olivier MATZ > wrote: > >> Hello Helmut, >> >> >> 2014-07-16 13:56, Helmut Sim: >> >>> then i see that from time to time i get a packet that was already >>>> received >>>> earlier instead of receiving the expected packet. >>>> the output is: >>>> PKT 12201 >>>> PKT 12202 >>>> PKT 12203 >>>> PKT 12204 >>>> PKT 12205 >>>> PKT 12206 >>>> PKT 12202 >>>> PKT 12208 >>>> >>>> total received pkts is identical to the total delivered pkts, but part >>>> of >>>> the pkts are being received twice... >>>> >>> >> Enabling CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG and >> CONFIG_RTE_LIBRTE_MBUF_DEBUG could help you to track >> double free or corruptions. >> >> Regards, >> Olivier >> >> >