From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) by dpdk.org (Postfix) with ESMTP id D9E0A68BC for ; Tue, 18 Feb 2014 18:17:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1392743920; x=1424279920; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QHjpYYI4hWUXxaSoIDBsdbYgpZxlQDpcXH5oOhwOupI=; b=BnYH5jSR8xkkSvw8htWL0RmyhDlxkf2J3XNG9z3sydEpIEBtrFx9gr5c TvkUAe/NfGFd6Mf/sUdjAVAO/HSV3oMagkBUs1rsmzwFF9hCqfBccK4w6 hGLCuOGZVOapeCpjRA1wT5OANA2O77CzSt+dGfB40UnUFYiLvXR5kJm52 4=; X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="82684357" Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2014 17:16:41 +0000 Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com [10.185.176.13]) by smtp-in-9003.sea19.amazon.com (8.14.7/8.14.7) with ESMTP id s1IHGfW7028636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 18 Feb 2014 17:16:41 GMT Received: from EX10-MBX-36002.ant.amazon.com ([fe80::cd97:16ef:48e8:b9f5]) by ex10-hub-31006.ant.amazon.com ([::1]) with mapi id 14.02.0342.003; Tue, 18 Feb 2014 09:16:10 -0800 From: "Benson, Bryan" To: Periklis Akritidis , Mario Gianni Thread-Topic: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Thread-Index: AQHPLJQXIfQWy/916k6cMwMFxE/Thpq7ldsA//+pgyA= Date: Tue, 18 Feb 2014 17:16:10 +0000 Message-ID: References: <20140218102749.270040@gmx.com>, <78841534-98AB-4845-9FAF-CAC975D15D3A@niometrics.com> In-Reply-To: <78841534-98AB-4845-9FAF-CAC975D15D3A@niometrics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.1.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) 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, 18 Feb 2014 17:17:15 -0000 Whoa, be careful, we used a custom init function and had a nasty bug becaus= e we assumed it was called on mbuf_free as well. The rte_pktmbuf_init func= tion pointer passed into mempool create is only used at pool initialization= time, not when an mbuf is freed - A reference to the obj_initi function is= not stored anywhere for future use during mbuf_free.=0A= =0A= Some of the fields are reset when the NIC has completed the send of the mbu= fs, but it does not use a custom function ptr.=0A= =0A= Thanks,=0A= Bryan Benson=0A= =0A= ________________________________________=0A= From: dev [dev-bounces@dpdk.org] on behalf of Periklis Akritidis [akritid@n= iometrics.com]=0A= Sent: Tuesday, February 18, 2014 6:19 AM=0A= To: Mario Gianni=0A= Cc: dev@dpdk.org=0A= Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)=0A= =0A= Hi Mario,=0A= =0A= Are you passing rte_pktmbuf_init as the obj_init argument to rte_mempool_cr= eate?=0A= It is called when the mbuf if freed and it will reset the fields. I vaguely= remember I had the same issue at some point and resolved it somehow. This = comes to mind.=0A= =0A= Cheers,=0A= Periklis=0A= =0A= On 18 Feb, 2014, at 6:27 pm, Mario Gianni wrote:=0A= =0A= > Hi all, I'm experimenting some code with DPDK v1.5.0 and I have the follo= wing problem:=0A= >=0A= > I have a thread that receives packets from NIC, once I received a packet = I want to prepend some data to it and I try to do so through the function r= te_pktmbuf_prepend()=0A= > then the packet is enqueued in a ring buffer where it will be used by a c= lient thread before being dropped through the function rte_pktmbuf_free() c= alled by the client thread.=0A= >=0A= > Now, if I try to send packets to this program I have the following behavi= our:=0A= > In a first time it seems to work correctly, then after a certain number o= f received packets (approximately the same number as the number of mbufs pr= esent in the mempool) if I call the rte_pktmbuf_headroom it returns that th= e headroom is shrinking more than the expected, until after a certain numbe= r of packets the headroom goes to zero.=0A= >=0A= > It seems like that when I call the rte_pktmbuf_free() function it doesn't= reset the data position inside the mbuf, so when I call for a second time = the mbuf the headroom continues to shrink until it finishes.=0A= >=0A= >=0A= > Do you have any idea of this strange behaviour?Could it be a bug in the p= repend/free function?=0A= >=0A= >=0A= > Thank you,=0A= >=0A= > Mario=0A= =0A=