From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 8EE2D592A for ; Thu, 30 Jan 2014 17:27:21 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 30 Jan 2014 08:28:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,750,1384329600"; d="scan'208";a="447141684" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga001.jf.intel.com with ESMTP; 30 Jan 2014 08:28:09 -0800 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 30 Jan 2014 08:27:13 -0800 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.111]) by fmsmsx115.amr.corp.intel.com ([10.18.116.19]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 08:27:13 -0800 From: "Rogers, Gerald" To: Prashant Upadhyaya , Pravin Shelar Thread-Topic: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports. Thread-Index: AQHPHTk78b8dpMP2+EuVCmqpJNbK+ZqdlDSA///yXYA= Date: Thu, 30 Jan 2014 16:27:12 +0000 Message-ID: References: <1390873715-26714-1-git-send-email-pshelar@nicira.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.34.84.232] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <29F76332244B8F41B71ADBEA91DA0E3E@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 30 Jan 2014 17:39:41 +0100 Cc: "dev@openvswitch.org" , "dev@dpdk.org" , "dpdk-ovs@lists.01.org" Subject: Re: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports. 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: Thu, 30 Jan 2014 16:27:22 -0000 Prashant, IVShm is supported by the Intel DPDK client rings, and a patched QEMU/KVM from the OVDK work on 01.org (https://01.org/packet-processing). The main part being the patched QEMU/KVM to map the Intel DPDK Huge Page Tables (with Release of Intel DPDK 1.6 the requirement to map 1 GB huge pages has been removed, but still supported) into the QEMU/KVM ivshm device (the Client rings are standard in Intel DPDK releases). My suggestion to add this functionality is similar to the way different interfaces are supported under Linux (tap, socket, etc.). Basically add another Intel DPDK Netdev type for client rings. Once the rings are instantiated (upon Intel DPDK initialization), then it is simple enough to have the OpenVSwitch control to initialize them into the polling method (just like the physical ports are done today). Structures like mac address, MTU, etc. for the would need to be considered since the client rings are not really thought of as =B3Ethernet=B2 ports within DPDK. If you want to make them virtual =B3Ethernet=B2 ports, then assigning the Ethernet parameters a static value upon initialization would be acceptable. Thoughts from the community are much welcomed on this whole topic. As Pravin mentioned in one of his previous e-mails, the support for IVShmem, Intel DPDK QOS, vxLan etc. wasn=B9t added (and in some cases doesn=B9t exist as an Intel DPDK library, ie. vxLan) to simplify the patch. It will be worked on for subsequent patches. Sincerely, Gerald On 1/30/14, 3:15 AM, "Prashant Upadhyaya" wrote: >Hi Pravin, > >Request you to please validate atleast one method to interface VM's with >your innovative dpdk port on the OVS. >Preferably IVSHM. >Please do publish the steps for that too. > >We really need the above for huge acceptance. > >Regards >-Prashant > > >-----Original Message----- >From: Pravin Shelar [mailto:pshelar@nicira.com] >Sent: Thursday, January 30, 2014 3:00 AM >To: Prashant Upadhyaya >Cc: dev@openvswitch.org; dev@dpdk.org; dpdk-ovs@lists.01.org; Gerald >Rogers >Subject: Re: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK >based ports. > >On Wed, Jan 29, 2014 at 12:56 AM, Prashant Upadhyaya > wrote: >> Hi Pravin, >> >> I think your stuff is on the brink of a creating a mini revolution :) >> >> Some questions inline below -- >> + ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=3Ddpdk >> What do you mean by portid here, do you mean the physical interface id >>like eth0 which I have bound to igb_uio now ? >> If I have multiple interfaces I have assigned igb_uio to, eg. eth0, >>eth1, eth2 etc., what is the id mapping for those ? >> >Port id is id assigned by DPDK. DPDK interface takes this port id as >argument. Currently you need to look at pci id to figure out the device >mapping to port id. I know it is clean and I am exploring better >interface so that we can specify device names to ovs-vsctl. > >> If I have VM's running, then typically how to interface those VM's to >>this OVS in user space now, do I use the same classical 'tap' interface >>and add it to the OVS above. > >tap device will work, but you would not get performance primarily due to >scheduling delay and memcopy. >DPDK has multiple drivers to create interface with KVM guests OS. >those should perform better. I have no tried it yet. > >> What is the actual path the data takes from the VM now all the way to >>the switch, wouldn't it be hypervisor to kernel to OVS switch in user >>space to other VM/Network ? > >Depends on method you use. e.g. Memnic bypass hypervisor and host kernel >entirely. > >> I think if we can solve the VM to OVS port connectivity remaining in >>userspace only, then we have a great thing at our hand. Kindly comment >>on this. >> >right, performance looks pretty good. Still DPDK needs constant polling >which consumes more power. RFC ovs-dkdp patch has simple polling which >need tweaking for better power usage. > >Thanks, >Pravin. > > > >> Regards >> -Prashant >> >> > > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D >Please refer to http://www.aricent.com/legal/email_disclaimer.html >for important disclosures regarding this electronic communication. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D