From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by dpdk.org (Postfix) with ESMTP id C5B6E8F9C for ; Wed, 21 Oct 2015 06:36:00 +0200 (CEST) Received: by padhk11 with SMTP id hk11so42468204pad.1 for ; Tue, 20 Oct 2015 21:36:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=E+9kDgFgd2vl89X/z86blRG5fjJb8N1LGn9AFBxoFec=; b=fSzpywT3R50/RapXIB/UYwk9uTuIqFtXGO3comH/lDQymnsf73RJ+ep95VX4TDGqoN fXKoEMCSdFVjyAsg7bcJePcn4KXpKiEnLO6WPCyLR0YHS5bxjkgj/qk8cyADAtuAe+2T YSArRix/tYYOdFSN5+GhJZdF8XpXLWKI0mOqqj34bFXEWnRDJWrCCZc7840g2rxPPr0R d12YkdaNmr6GzVlsfyrgXIlsuYRgKH8GAth/WaWrG2V/+B3rzygQ0co2XpC2l931dYV5 gis3bOlmyo+hQirCrtuLTb1oJE6aSN9EwXt7KubFRqL24f7m+3XGktyANxs+hN6LnlsT i24Q== X-Gm-Message-State: ALoCoQkXfhYkqyyTrdyAZaDbAKvXeDQTA32ri41LUW1WIShEYnRxas4YsN4/Cilwydosc8poI2Jq X-Received: by 10.66.248.227 with SMTP id yp3mr8255579pac.108.1445402160005; Tue, 20 Oct 2015 21:36:00 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id ir5sm6578569pbc.13.2015.10.20.21.35.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 21:35:59 -0700 (PDT) From: Tetsuya Mukawa To: "Richardson, Bruce" , Panu Matilainen , "Loftus, Ciara" References: <1440993326-21205-1-git-send-email-mukawa@igel.co.jp> <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> X-Enigmail-Draft-Status: N1110 Message-ID: <5627162C.1030108@igel.co.jp> Date: Wed, 21 Oct 2015 13:35:56 +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: <59AF69C657FD0841A61C55336867B5B03595DBA8@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 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: Wed, 21 Oct 2015 04:36:01 -0000 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. Thanks, Tetsuya