From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by dpdk.org (Postfix) with ESMTP id 363D72C28 for ; Mon, 13 Mar 2017 20:17:41 +0100 (CET) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id v2DJHXmv011023 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Mon, 13 Mar 2017 12:17:33 -0700 Received: from ALA-MBC.corp.ad.wrs.com ([fe80::fcbe:9b7:1141:89a1]) by ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) with mapi id 14.03.0294.000; Mon, 13 Mar 2017 12:17:32 -0700 From: "Legacy, Allain" To: Vincent JARDIN , "YIGIT, FERRUH" CC: "Jolliffe, Ian" , "jerin.jacob@caviumnetworks.com" , "stephen@networkplumber.org" , "thomas.monjalon@6wind.com" , "dev@dpdk.org" , "WILES, ROGER" Thread-Topic: [dpdk-dev] [PATCH v3 16/16] doc: adds information related to the AVP PMD Thread-Index: AQHSlDpCNQdSpjmygkmnxqcNs3g3wqGTAizw Date: Mon, 13 Mar 2017 19:17:31 +0000 Message-ID: <70A7408C6E1BFB41B192A929744D8523968EE5D2@ALA-MBC.corp.ad.wrs.com> References: <1488136143-116389-1-git-send-email-allain.legacy@windriver.com> <1488414008-162839-1-git-send-email-allain.legacy@windriver.com> <1488414008-162839-17-git-send-email-allain.legacy@windriver.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.224.140.166] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 16/16] doc: adds information related to the AVP PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:17:41 -0000 Vincent, Perhaps you can help me understand why the performance or functionality of = AVP vs. Virtio is relevant to the decision of accepting this driver. Ther= e are many drivers in the DPDK; most of which provide the same functionalit= y at comparable performance rates. AVP is just another such driver. The = fact that it is virtual rather than physical, in my opinion, should not inf= luence the decision of accepting this driver. On the other hand, code qua= lity/complexity or lack of a maintainer are reasonable reasons for rejectin= g. If our driver is accepted we are committed to maintaining it and test= ing changes as required by any driver framework changes which may impact al= l drivers. Along the same lines, I do not understand why upstreaming AVP in to the Lin= ux kernel or qemu/kvm should be a prerequisite for inclusion in the DPDK. = Continuing my analogy from above, the AVP device is a commercial offering = tied to the Wind River Systems Titanium product line. It enables virtuali= zed DPDK applications and increases DPDK adoption. Similarly to how a dri= ver from company XYX is tied to a commercial NIC that must be purchased by = a customer, our AVP device is available to operators that choose to leverag= e our Titanium product to implement their Cloud solutions. It is not our= intention to upstream the qemu/kvm or host vswitch portion of the AVP devi= ce. Our qemu/kvm extensions are GPL so they are available to our customer= s if they desire to rebuild qemu/kvm with their own proprietary extensions Our AVP device was implemented in 2013 in response to the challenge of lowe= r than required performance of qemu/virtio in both user space and DPDK appl= ications in the VM. Rather than making complex changes to qemu/virtio and= continuously have to forward prop those as we upgraded to newer versions o= f qemu we decided to decouple ourselves from that code base. We developed= the AVP device based on an evolution of KNI+ivshmem by enhancing both with= features that would meet the needs of our customers; better performance, m= ulti-queue support, live-migration support, hot-plug support. As I said = in my earlier response, since 2013, qemu/virtio has seen improved performan= ce with the introduction of vhost-user. The performance of vhost-user sti= ll has not yet achieved performance levels equal to our AVP PMD. =20 I acknowledge that the AVP driver could exist as an out-of-tree driver load= ed as a shared library at runtime. In fact, 2 years ago we released our dr= iver source on github for this very reason. We provide instructions and su= pport for building the AVP PMD as a shared library. Some customers have a= dopted this method while many insist on an in-tree driver for several reaso= ns. =20 Most importantly, they want to eliminate the burden of needing to build and= support an additional package into their product. An in-tree driver woul= d eliminate the need for a separate build/packaging process. Also, they w= ant an option that allows them to be able to develop directly on the bleedi= ng edge of DPDK rather than waiting on us to update our out-of-tree driver = based on stable releases of the DPDK. In this regard, an in-tree driver w= ould allow our customers to work directly on the latest DPDK.=20 An in-tree driver provides obvious benefits to our customers, but keep in m= ind that this also provides a benefit to the DPDK. If a customer must deve= lop on a stable release because they must use an out-of-tree driver then th= ey are less likely to contribute fixes/enhancements/testing upstream. I kn= ow this first hand because I work with software from different sources on a= daily basis and it is a significant burden to have to reproduce/test fixes= on master when you build/ship on an older stable release. Accepting this= driver would increase the potential pool of developers available for contr= ibutions and reviews. Again, we are committed to contributing to the DPDK community by supporting= our driver and upstreaming other fixes/enhancements we develop along the w= ay. We feel that if the DPDK is limited to only a single virtual driver o= f any type then choice and innovation is also limited. In the end if more= variety and innovation increases DPDK adoption then this is a win for DPDK= and everyone that is involved in the project. Regards, Allain Allain Legacy, Software Developer direct 613.270.2279=A0=A0fax 613.492.7870 skype allain.legacy =A0 > -----Original Message----- > From: Vincent JARDIN [mailto:vincent.jardin@6wind.com] > Sent: Friday, March 03, 2017 11:22 AM > To: Legacy, Allain; YIGIT, FERRUH > Cc: Jolliffe, Ian; jerin.jacob@caviumnetworks.com; > stephen@networkplumber.org; thomas.monjalon@6wind.com; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 16/16] doc: adds information related to > the AVP PMD >=20 > Le 02/03/2017 =E0 01:20, Allain Legacy a =E9crit : > > +Since the initial implementation of AVP devices, vhost-user has become > > +part of the qemu offering with a significant performance increase over > > +the original virtio implementation. However, vhost-user still does > > +not achieve the level of performance that the AVP device can provide > > +to our customers for DPDK based VM instances. >=20 > Allain, >=20 > please, can you be more explicit: why is virtio not fast enough? >=20 > Moreover, why should we get another PMD for Qemu/kvm which is not > virtio? There is not argument into your doc about it. > NEC, before vhost-user, made a memnic proposal too because > virtio/vhost-user was not available. > Now, we all agree that vhost-user is the right way to support VMs, it > avoids duplication of maintenances. >=20 > Please add some arguments that explains why virtio should not be used, > so others like memnic or avp should be. >=20 > Regarding, > + nova boot --flavor small --image my-image \ > + --nic net-id=3D${NETWORK1_UUID} \ > + --nic net-id=3D${NETWORK2_UUID},vif-model=3Davp \ > + --nic net-id=3D${NETWORK3_UUID},vif-model=3Davp \ > + --security-group default my-instance1 >=20 > I do not see how to get it working with vanilla nova. Please, I think > you should rather show with qemu or virsh. >=20 > Then, there is not such AVP netdevice into Linux kernel upstream. Before > adding any AVP support, it should be added into legacy upstream so we > can be sure that the APIs will be solid and won't need to be updated > because of some kernel constraints. >=20 > Thank you, > Vincent