From mboxrd@z Thu Jan 1 00:00:00 1970 From: Meir Tseitlin Subject: Re: Weird behavior of DPDK - ongoing problem Date: Mon, 14 Apr 2014 10:46:57 +0300 Message-ID: References: <534B8C52.8070003@igel.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: dev-VfR2kkLFssw@public.gmane.org To: "Tetsuya.Mukawa" Return-path: In-Reply-To: <534B8C52.8070003-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Ok, I think I figured it out - this issue was partly my fault. I do work with 1.6r0 and I also use Pcap driver. Pcap driver still contains bug which does not properly release all packets in rte_eth_tx_burst, causing application to run out of memory. I addressed this problem wrongly by manually releasing them before they actually sent. This caused early reallocation. Anyway, thanks for help! Meir Tseitlin On Mon, Apr 14, 2014 at 10:20 AM, Tetsuya.Mukawa wrote: > Hi Meir, > > (2014/04/13 19:21), Meir Tseitlin wrote: > > The problem is that in 30% of the cases data packet enters the path of > > control packet instead of expected answer. Which probably means that > after > > my packet type check, the mbuf is overwritten before handled properly. > If you are using DPDK-1.5, it's nice to update to DPDK-1.6, because pcap > pmd of DPDK-1.5 has buffer overflow while receiving data from a target > device/file. And the issue was solved with DPDK-1.6 (in both intel > original code and dpdk.org code). > > Also if multiple processes/threads run on a same cpu, probably, it could > cause a problem like you're facing. > > Regards, > Tetsuya > -- Kind regards, *Meir Tseitlin* Software architect*Mobile:* +972.54.7647417 *Fax:* +972.72.2812365 *Email:* meir.tech-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org *http://il.linkedin.com/in/meirts * *Independent consultant* See who we know in commonWant a signature like this?