From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id 68E248E70 for ; Mon, 19 Oct 2015 12:50:31 +0200 (CEST) Received: by pasz6 with SMTP id z6so27489522pas.2 for ; Mon, 19 Oct 2015 03:50:30 -0700 (PDT) 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=fknArHwh6PVHDaZ0qByCAeuJhW6yClWsVgLLCvkM7i8=; b=Wt8yKYaf6AbtDZH6i45ZOZ6ZjmboCiQt5MeM6SElWSwSzajdffhMqg344Su2bOcZBE RI1EmlxD6d4xOPztOeMcEIFy5FJbWKqbzK0j5Oa9GSotSB36l3zsbQD+uXX0svrvQ9QF Zua8FVMBbykoxvxBix0jiI9KigeFYiY7hvZSi+aeWHlIfWdKAetV9P6b9OM2+cpnKDM4 TC4S88BvMpqjXCJMyCTbBV6/DhEZVLrrvgsFoaAKVe+6f6qYo1IN4WXV1Cw8pmi1yaDG 4EYrBOREVX6AGLFFfrP6yNajs5Wlol++4XGvx2DqevY1ghazKg52WB8fVPJ+y4UXJJnD Xukg== X-Gm-Message-State: ALoCoQky896MAHvkNq2ezTshdj8kJ8Z49I42Sk4ieUINh8Bqkq3M9x/AQp1VPTHKZmfSqJh+5/oo X-Received: by 10.68.102.2 with SMTP id fk2mr33566393pbb.129.1445251830568; Mon, 19 Oct 2015 03:50:30 -0700 (PDT) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id ph8sm4156317pbc.8.2015.10.19.03.50.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 03:50:29 -0700 (PDT) To: Bruce Richardson , "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> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <5624CAF2.10201@igel.co.jp> Date: Mon, 19 Oct 2015 19:50:26 +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: <20151019094532.GB11324@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: Mon, 19 Oct 2015 10:50:31 -0000 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. Regards, Tetsuya