From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by dpdk.org (Postfix) with ESMTP id F0376958A for ; Thu, 22 Oct 2015 11:50:07 +0200 (CEST) Received: by pabrc13 with SMTP id rc13so82723859pab.0 for ; Thu, 22 Oct 2015 02:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel_co_jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=IUG4FL0AwoqbTpPEnOpMUKGj466uBu/CnYE7867s5Q4=; b=xwU0kNaaZqWv4fBqGJwWqtXY82Vi83zOHHvoIBBUW1VFfaToC9sQcRY1hnLuAyxpsR EtLVPcivej3t45BQhrzZegDI2R7i1cqTa09EeaydgEoy9Q1AIIiWIQc/WjaevGAro7Aw nGc3+HYTXr0iB7AO/aSXgpWQpVcQ5ZCBoTh7pFz4Xsj8EpO9qcUQzVMFlcDPTwNkvzrj S1viHMNfBY3VK1Mor6dh9D73H8HzU4TeyDlvXwJnRejb03l5nVws6B16KjuBAdFod7Yv ecIzARIWxBBbvoOUvCEW4AsmmEl3JfnsuYaC/n6sHz++LesTLpRBVWvhtG3pAc0Y1lBS vXxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=IUG4FL0AwoqbTpPEnOpMUKGj466uBu/CnYE7867s5Q4=; b=CJQU9DrYOGpFD85QW+oL4Imx/v7ZpAhJL9Po6sON5mDiGqDKhewANctBfqYsbMqYr4 FNi+Xu3BMX9m7ONiLh1fsJihBRLKoI93zGhXsaILDR4YaE1ddQ1Nj+uUoaZ9R6PxSv+P AqhtxG19GXQJidxVQnDXJyMB+BrgDNQmsEqhN0P9dpolDvorHkcBwfgXsmSyMLejbnrE 2nxzSUNdZVHi4zjKHQuImsnJe2nSpszCwBPGNO4vFsZTzgnHDZT9iG6USDaqfcOE8XCf RrdhUQXcYey090qJsE0mbyCpMfLDt2IUpXZRcofKz1AElkiejTkw6h82uNefM+Q5ybn6 uPrg== X-Gm-Message-State: ALoCoQmo7ZnxcQ68/LCTP2UXjRhViCKbYdZ5Qt+vmKi3ZAJEQgB3nzvc8JLb4iks9BsaYxs92YPR X-Received: by 10.68.225.138 with SMTP id rk10mr16089077pbc.121.1445507407285; Thu, 22 Oct 2015 02:50:07 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id qa5sm13165947pbc.70.2015.10.22.02.50.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2015 02:50:06 -0700 (PDT) To: Bruce Richardson , Panu Matilainen References: <1440993326-21205-2-git-send-email-mukawa@igel.co.jp> <20151016125254.GA9980@bricha3-MOBL3> <56244C84.4090309@igel.co.jp> <74F120C019F4A64C9B78E802F6AD4CC24F7A881E@IRSMSX106.ger.corp.intel.com> <20151019094532.GB11324@bricha3-MOBL3> <5624CAF2.10201@igel.co.jp> <5624EF7D.9090908@redhat.com> <59AF69C657FD0841A61C55336867B5B03595DBA8@IRSMSX103.ger.corp.intel.com> <5627162C.1030108@igel.co.jp> <56272FC8.2020305@redhat.com> <20151021102238.GB16140@bricha3-MOBL3> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <5628B14A.8020902@igel.co.jp> Date: Thu, 22 Oct 2015 18:50:02 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151021102238.GB16140@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "ann.zhuangyanying@huawei.com" Subject: Re: [dpdk-dev] [RFC PATCH v2] vhost: Add VHOST PMD 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, 22 Oct 2015 09:50:08 -0000 On 2015/10/21 19:22, Bruce Richardson wrote: > On Wed, Oct 21, 2015 at 09:25:12AM +0300, Panu Matilainen wrote: >> On 10/21/2015 07:35 AM, Tetsuya Mukawa wrote: >>> On 2015/10/19 22:27, Richardson, Bruce wrote: >>>>> -----Original Message----- >>>>> From: Panu Matilainen [mailto:pmatilai@redhat.com] >>>>> Sent: Monday, October 19, 2015 2:26 PM >>>>> To: Tetsuya Mukawa ; Richardson, Bruce >>>>> ; Loftus, Ciara >>>>> Cc: dev@dpdk.org; ann.zhuangyanying@huawei.com >>>>> Subject: Re: [dpdk-dev] [RFC PATCH v2] vhost: Add VHOST PMD >>>>> >>>>> On 10/19/2015 01:50 PM, Tetsuya Mukawa wrote: >>>>>> On 2015/10/19 18:45, Bruce Richardson wrote: >>>>>>> On Mon, Oct 19, 2015 at 10:32:50AM +0100, Loftus, Ciara wrote: >>>>>>>>> On 2015/10/16 21:52, Bruce Richardson wrote: >>>>>>>>>> On Mon, Aug 31, 2015 at 12:55:26PM +0900, Tetsuya Mukawa wrote: >>>>>>>>>>> The patch introduces a new PMD. This PMD is implemented as thin >>>>>>>>> wrapper >>>>>>>>>>> of librte_vhost. It means librte_vhost is also needed to compile >>>>> the PMD. >>>>>>>>>>> The PMD can have 'iface' parameter like below to specify a path >>>>>>>>>>> to >>>>>>>>> connect >>>>>>>>>>> to a virtio-net device. >>>>>>>>>>> >>>>>>>>>>> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0' -- -i >>>>>>>>>>> >>>>>>>>>>> To connect above testpmd, here is qemu command example. >>>>>>>>>>> >>>>>>>>>>> $ qemu-system-x86_64 \ >>>>>>>>>>> >>>>>>>>>>> -chardev socket,id=chr0,path=/tmp/sock0 \ >>>>>>>>>>> -netdev vhost-user,id=net0,chardev=chr0,vhostforce \ >>>>>>>>>>> -device virtio-net-pci,netdev=net0 >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Tetsuya Mukawa >>>>>>>>>> With this PMD in place, is there any need to keep the existing >>>>>>>>>> vhost library around as a separate entity? Can the existing >>>>>>>>>> library be >>>>>>>>> subsumed/converted into >>>>>>>>>> a standard PMD? >>>>>>>>>> >>>>>>>>>> /Bruce >>>>>>>>> Hi Bruce, >>>>>>>>> >>>>>>>>> I concern about whether the PMD has all features of librte_vhost, >>>>>>>>> because librte_vhost provides more features and freedom than ethdev >>>>>>>>> API provides. >>>>>>>>> In some cases, user needs to choose limited implementation without >>>>>>>>> librte_vhost. >>>>>>>>> I am going to eliminate such cases while implementing the PMD. >>>>>>>>> But I don't have strong belief that we can remove librte_vhost now. >>>>>>>>> >>>>>>>>> So how about keeping current separation in next DPDK? >>>>>>>>> I guess people will try to replace librte_vhost to vhost PMD, >>>>>>>>> because apparently using ethdev APIs will be useful in many cases. >>>>>>>>> And we will get feedbacks like "vhost PMD needs to support like this >>>>> usage". >>>>>>>>> (Or we will not have feedbacks, but it's also OK.) Then, we will be >>>>>>>>> able to merge librte_vhost and vhost PMD. >>>>>>>> I agree with the above. One the concerns I had when reviewing the >>>>> patch was that the PMD removes some freedom that is available with the >>>>> library. Eg. Ability to implement the new_device and destroy_device >>>>> callbacks. If using the PMD you are constrained to the implementations of >>>>> these in the PMD driver, but if using librte_vhost, you can implement your >>>>> own with whatever functionality you like - a good example of this can be >>>>> seen in the vhost sample app. >>>>>>>> On the other hand, the PMD is useful in that it removes a lot of >>>>> complexity for the user and may work for some more general use cases. So I >>>>> would be in favour of having both options available too. >>>>>>>> Ciara >>>>>>>> >>>>>>> Thanks. >>>>>>> However, just because the libraries are merged does not mean that you >>>>>>> need be limited by PMD functionality. Many PMDs provide additional >>>>>>> library-specific functions over and above their PMD capabilities. The >>>>>>> bonded PMD is a good example here, as it has a whole set of extra >>>>>>> functions to create and manipulate bonded devices - things that are >>>>>>> obviously not part of the general ethdev API. Other vPMDs similarly >>>>> include functions to allow them to be created on the fly too. >>>>>>> regards, >>>>>>> /Bruce >>>>>> Hi Bruce, >>>>>> >>>>>> I appreciate for showing a good example. I haven't noticed the PMD. >>>>>> I will check the bonding PMD, and try to remove librte_vhost without >>>>>> losing freedom and features of the library. >>>>> Hi, >>>>> >>>>> Just a gentle reminder - if you consider removing (even if by just >>>>> replacing/renaming) an entire library, it needs to happen the ABI >>>>> deprecation process. >>>>> >>>>> It seems obvious enough. But for all the ABI policing here, somehow we all >>>>> failed to notice the two compatibility breaking rename-elephants in the >>>>> room during 2.1 development: >>>>> - libintel_dpdk was renamed to libdpdk >>>>> - librte_pmd_virtio_uio was renamed to librte_pmd_virtio >>>>> >>>>> Of course these cases are easy to work around with symlinks, and are >>>>> unrelated to the matter at hand. Just wanting to make sure such things >>>>> dont happen again. >>>>> >>>>> - Panu - >>>> Still doesn't hurt to remind us, Panu! Thanks. :-) >>> Hi, >>> >>> Thanks for reminder. I've checked the DPDK documentation. >>> I will submit deprecation notice to follow DPDK deprecation process. >>> (Probably we will be able to remove vhost library in DPDK-2.3 or later.) >>> >>> BTW, I will merge vhost library and PMD like below. >>> Step1. Move vhost library under vhost PMD. >>> Step2. Rename current APIs. >>> Step3. Add a function to get a pointer of "struct virtio_net device" by >>> a portno. >>> >>> Last steps allows us to be able to convert a portno to the pointer of >>> corresponding vrtio_net device. >>> And we can still use features and freedom vhost library APIs provided. >> Just wondering, is that *really* worth the price of breaking every single >> vhost library user out there? >> >> I mean, this is not about removing some bitrotten function or two which >> nobody cares about anymore but removing (by renaming) one of the more widely >> (AFAICS) used libraries and its entire API. >> >> If current APIs are kept then compatibility is largely a matter of planting >> a strategic symlink or two, but it might make the API look inconsistent. >> >> But just wondering about the benefit of this merge thing, compared to just >> adding a vhost pmd and leaving the library be. The ABI process is not there >> to make life miserable for DPDK developers, its there to help make DPDK >> nicer for *other* developers. And the first and the foremost rule is simply: >> dont break backwards compatibility. Not unless there's a damn good reason to >> doing so, and I fail to see that reason here. >> >> - Panu - >> > Good question, and I'll accept that maybe it's not worth doing. I'm not that > much of an expert on the internals and APIs of vhost library. > > However, the merge I was looking for was more from a code locality point > of view, to have all the vhost code in one directory (under drivers/net), > than spread across multiple ones. What API's need to be deprecated > or not as part of that work, is a separate question, and so in theory we could > create a combined vhost library that does not deprecate anything (though to > avoid a build-up of technical debt, we'll probably want to deprecate some > functions). > > I'll leave it up to the vhost experts do decide what's best, but for me, any > library that handles transmission and reception of packets outside of a DPDK > app should be a PMD library using ethdev rx/tx burst routines, and located > under drivers/net. (KNI is another obvious target for such a move and conversion). > > Regards, > /Bruce > Hi, I have submitted latest patches. I will keep vhost library until we will have agreement to merge it to vhost PMD. Regards, Testuya