From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from inblrg02.tcs.com (inblrg02.tcs.com [121.242.48.116]) by dpdk.org (Postfix) with ESMTP id E1D272BB8 for ; Tue, 16 Aug 2016 08:41:02 +0200 (CEST) IronPort-PHdr: =?us-ascii?q?9a23=3AUatCzxBZeGqHx7Oro2YLUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP7yo8bcNUDSrc9gkEXOFd2CrakV0qyP7eu5ATJIoc7Y9itTKNoUD15NoP?= =?us-ascii?q?5VtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBke3blIt?= =?us-ascii?q?dazLE4Lfx/66y/q1s8WKJV4Z3XzkP/grdEv+7V2I8JJH2c06cud54yCKi0MAQ/?= =?us-ascii?q?5Ry2JsKADbtDfHzeD0wqRe9T9Nsekq7c9KXPayVa05SbtFEGZuaDhtt4XD/CPO?= =?us-ascii?q?RgqX53YaTn5e0l8RW1CEv1nGWcLXszD6v+xhkBeXJ8j/BeQqXzW57/4yYBDtgS?= =?us-ascii?q?YDcTU+9TeEpNZ3ifdhqRCo7z520ofMaYXdYOB3fKqbf9oLTHJIWu5NXDcHCYS5?= =?us-ascii?q?OdhcR9EdNPpV+tGu72AFqgGzUEz1XLvi?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DPAQDSsbJX/6fBE6xegneCIK0fjCiBf?= =?us-ascii?q?YYdAoIEFAIBAQEBAQEBAYEEgjIEARMBghMBAQUnUhAFBg0BAwMBAi8CHy4IBgs?= =?us-ascii?q?IEYgGA61MAQEBjGcNhC0BAQEBAQEBAQEBAQEBAQEBAQEBAQEODoYqhE2CQ4IUC?= =?us-ascii?q?QyDAIIvBY8QiXw0gWKBWoFzhmVDhCsXhESIfYgvhAiDeB6CRR+BVGaHKwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2DPAQDSsbJX/6fBE6xegneCIK0fjCiBfYYdAoIEFAIBAQE?= =?us-ascii?q?BAQEBAYEEgjIEARMBghMBAQUnUhAFBg0BAwMBAi8CHy4IBgsIEYgGA61MAQEBj?= =?us-ascii?q?GcNhC0BAQEBAQEBAQEBAQEBAQEBAQEBAQEODoYqhE2CQ4IUCQyDAIIvBY8QiXw?= =?us-ascii?q?0gWKBWoFzhmVDhCsXhESIfYgvhAiDeB6CRR+BVGaHKwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,529,1464633000"; d="pcap'?scan'208,217";a="28133291" X-DISCLAIMER: FALSE MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , From: Raja Jayapal To: Nishant Verma Cc: "users@dpdk.org" , Nagaratna Patagar Message-ID: Date: Tue, 16 Aug 2016 12:10:50 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP6HF144 June 24, 2016 X-MIMETrack: Serialize by http on InBlrM16/TCS(Release 9.0.1FP6HF144 | June 24, 2016) at 08/16/2016 12:10:50, Serialize complete at 08/16/2016 12:10:50, Itemize by http on InBlrM16/TCS(Release 9.0.1FP6HF144 | June 24, 2016) at 08/16/2016 12:10:50, Serialize by Router on InBlrM16/TCS(Release 9.0.1FP6HF144 | June 24, 2016) at 08/16/2016 12:10:51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] arp behaviour on dpdk X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 06:41:03 -0000 Hi Nishant, Please find attachment for the pcap file. Thanks, Raja -----Nishant Verma wrote: ----- To: Raja Jayapal From: Nishant Verma Date: 08/13/2016 02:42AM Cc: "users@dpdk.org" , Nagaratna Patagar Subject: Re: [dpdk-users] arp behaviour on dpdk Hi Raja, What i understand is that Br1(linux machine) is getting ARP request but not= sending ARP Response?=20 If this is the case, it means either packet is not liked by Br1 hence dropp= ed or some how capture is not right. Can you share pcap file,=A0 captured at Br1. On Thu, Aug 11, 2016 at 3:02 AM, Raja Jayapal wrote: Hi All, =20 I am running dpdk on KVM and would like to understand the arp behaviour on= dpdk ports. The topology is as below. =20 br0(192.168.100.10)----> vnet0 -----> dpdk(NIC1- e1000)------->dpdk(NIC2-e= 1000)------>vnet1----->br1(192.168.100.20) =20 I am sending ARP packet from br0 using PackETH tool destined to br1. I have=A0 edited the dpdk l2fwd code in such a way that , the destination = is broadcast address(ffff). In br1 , i can see the arp resquest, but the host bridge is not responding= for the arp request. =20 In br1: =3D=3D=3D=3D=3D tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes 12:21:15.459667 ARP, Request who-has 192.168.100.20 (00:0a:e7:2c:44:2b (ou= i Unknown)) tell 192.168.100.10, length 46 12:21:15.651610 ARP, Request who-has 192.168.100.20 (00:0a:e7:2c:44:2b (ou= i Unknown)) tell 192.168.100.10, length 46 12:21:15.867692 ARP, Request who-has 192.168.100.20 (00:0a:e7:2c:44:2b (ou= i Unknown)) tell 192.168.100.10, length 46 =20 In l2fwd application example also, the arp packets are getting received on= the adjacent ports, but the arp reply has not been sent back from br1. =20 Could you please let me know how to make the host(br1) to reply the arp re= quest. =20 Thanks, Raja =20 =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you =20 =20 =20 --=20 Rgds, Nishant =20 >From sergio.gonzalez.monroy@intel.com Tue Aug 16 09:37:03 2016 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 76AAE5A43; Tue, 16 Aug 2016 09:37:03 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 16 Aug 2016 00:36:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,529,1464678000"; d="scan'208";a="866126625" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.220.36]) ([10.237.220.36]) by orsmga003.jf.intel.com with ESMTP; 16 Aug 2016 00:36:44 -0700 To: "Harris, James R" , Thomas Monjalon , "users@dpdk.org" , "dev@dpdk.org" , "Richardson, Bruce" References: <1470871839.40000.48.camel@intel.com> <1549431.MJntLMElOg@xps13> Cc: "Verkamp, Daniel" From: Sergio Gonzalez Monroy Message-ID: <8b8e180e-a996-ef6e-cbf8-23028a194224@intel.com> Date: Tue, 16 Aug 2016 08:36:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-users] [dpdk-dev] rte_zmalloc() returning non-zeroed memory on FreeBSD X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 07:37:04 -0000 On 15/08/2016 18:23, Harris, James R wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon >> Sent: Thursday, August 11, 2016 12:05 AM >> To: users@dpdk.org; dev@dpdk.org; Gonzalez Monroy, Sergio; Richardson, >> Bruce >> Cc: Verkamp, Daniel >> Subject: Re: [dpdk-dev] [dpdk-users] rte_zmalloc() returning non-zeroed >> memory on FreeBSD >> >> Hi, >> >> 2016-08-10 23:30, Verkamp, Daniel: >>> It seems that with DPDK 16.07, rte_zmalloc() and related functions no >>> longer return zeroed memory reliably on FreeBSD. >>> >>> I notice that commit b78c9175118f7d61022ddc5c62ce54a1bd73cea5 ("mem: >> do >>> not zero out memory on zmalloc") removed the explicit memset() that >> used >>> to ensure the buffer was zeroed; its log message says: >>> >>> "Zeroing out memory on rte_zmalloc_socket is not required anymore since >>> all allocated memory is already zeroed." >> On Linux, the memory is zeroed by the kernel. >> Then the zero value is maintained in the rte_malloc pool by rte_free. >> >>> However, I don't see how this is guaranteed (at least for FreeBSD), and >>> it is not true in practice. I've attached a minimized reproducer program - >>> running it twice in a row fails reliably for me. >>> >>> Is there a missing step in FreeBSD, or is it a more general problem for >>> other platforms? >> I guess the initial value from the kernel has been verified only on Linux. >> We could re-add a memset for FreeBSD. > The problem is that the FreeBSD contigmem driver does not re-zero the huge > pages each time they are mmap'd - they are only zeroed when contigmem > initially loads. I will push a patch for this shortly. So that is the case where we run the app more than once, right? I missed that, I only ran it once. Sergio