Re: [dpdk-users] arp behaviour on dpdk

[Raja Jayapal <raja.jayapal@tcs.com>]

Hi Nishant,

Please find attachment for the pcap file.

Thanks,
Raja

-----Nishant Verma <vnish11@gmail.com> wrote: -----
To: Raja Jayapal <raja.jayapal@tcs.com>
From: Nishant Verma <vnish11@gmail.com>
Date: 08/13/2016 02:42AM
Cc: "users@dpdk.org" <users@dpdk.org>, Nagaratna Patagar <nagaratna.patagar@tcs.com>
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? 
If this is the case, it means either packet is not liked by Br1 hence dropped or some how capture is not right.

Can you share pcap file,  captured at Br1.



On Thu, Aug 11, 2016 at 3:02 AM, Raja Jayapal <raja.jayapal@tcs.com> wrote:
Hi All,
 
 I am running dpdk on KVM and would like to understand the arp behaviour on dpdk ports.
 The topology is as below.
 
 br0(192.168.100.10)----> vnet0 -----> dpdk(NIC1- e1000)------->dpdk(NIC2-e1000)------>vnet1----->br1(192.168.100.20)
 
 I am sending ARP packet from br0 using PackETH tool destined to br1.
 I have  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.
 
 In br1:
 =====
 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 (oui 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 (oui 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 (oui Unknown)) tell 192.168.100.10, length 46
 
 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.
 
 Could you please let me know how to make the host(br1) to reply the arp request.
 
 Thanks,
 Raja
 
 =====-----=====-----=====
 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
 
 
 


-- 
Rgds,
Nishant



  
From sergio.gonzalez.monroy@intel.com  Tue Aug 16 09:37:03 2016
Return-Path: <sergio.gonzalez.monroy@intel.com>
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" <james.r.harris@intel.com>,
 Thomas Monjalon <thomas.monjalon@6wind.com>, "users@dpdk.org"
 <users@dpdk.org>, "dev@dpdk.org" <dev@dpdk.org>,
 "Richardson, Bruce" <bruce.richardson@intel.com>
References: <1470871839.40000.48.camel@intel.com> <1549431.MJntLMElOg@xps13>
 <A35C21583F92CE4D8ADBF9D61694E910216BF49B@FMSMSX105.amr.corp.intel.com>
Cc: "Verkamp, Daniel" <daniel.verkamp@intel.com>
From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
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: <A35C21583F92CE4D8ADBF9D61694E910216BF49B@FMSMSX105.amr.corp.intel.com>
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 <users.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=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