Re: [dpdk-dev] [PATCH RFC] dpif-netdev: Add support Intel DPDK based ports.

["Rogers, Gerald" <gerald.rogers@intel.com>]

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 ³Ethernet² ports within DPDK.  If you want to make
them virtual ³Ethernet² 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¹t added (and in some cases
doesn¹t 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" <prashant.upadhyaya@aricent.com>
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
><prashant.upadhyaya@aricent.com> 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=dpdk
>> 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
>>
>>
>
>
>
>
>==========================================================================
>=====
>Please refer to http://www.aricent.com/legal/email_disclaimer.html
>for important disclosures regarding this electronic communication.
>==========================================================================
>=====