From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by dpdk.org (Postfix) with ESMTP id 5C98A2E83 for ; Fri, 20 Nov 2015 03:53:43 +0100 (CET) Received: by pabfh17 with SMTP id fh17so104239382pab.0 for ; Thu, 19 Nov 2015 18:53:42 -0800 (PST) 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=3B9uVm1mZ40oEkmvR/cuhLFATNsoYfpTFtlG0lZ4zsc=; b=p2vPGzOPniPovFcn0ANtIxkChC0vgA9mf430adVv03Y+FzMF7zihFm+xVRvgahFVUY YUCSJD6N6B/CR3ilLX44jgYuofz7BNyJJ48/eQDkb76fCGtFs+zu0/EAyC4fm61F1GzT qz8DcAkB+hnTo5G3iBt8TCk5ppkHFsGsEAbfs9PyfVL5QqY++v2zELuPeJCgKayffQQf XZ/9aF8JCWevaJCienOIdtX4jsxqFm+7SEuYDB1PjmdaImMEfyADY0AWX9NKPf7tQy8e bL1aGbK0/K5gHPevHIU2Bsab4tcSy91YNdhK9E4yAcRX/OgggGPyoOVYIYY5WjUqvONC lTLA== 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=3B9uVm1mZ40oEkmvR/cuhLFATNsoYfpTFtlG0lZ4zsc=; b=FDMknRTRUxeL5x/rpsdNIQxbIIxue2vdn3kmAJFH+XnMNIt2OE8bAPqbsJ9SHLf/MC xND5gREhYfJ9+gRAUOPWB+NYDeEbe5ejhM5vAHmIMNeEunfX0E1hyhtNIuoOtRLj5HBB wSOrjYQUGfeKLPLNU9p/m2W+Ek1WglZmAlYWoaIA3Qxlz0Y5JD8QOePxqr+HnVVS3jWV 48NgP9iB1SOmDGOTEM0O7g29eZlaMT+7hFzcStFwENbfhtZRYRq5T0zdIvCwCBmObwWr FmcLNcFacrSOjwEYzT5I7r0U9+mnlMKpgehE/FY3ntbSdaDulhiclSl/Tv9YHKZrXlbW f9hg== X-Gm-Message-State: ALoCoQmuqxjOXBTVuQXLjsKhm5klc6RdINg3JNRU8KGgzOAGhEuLU2Yol2967g50Y5t3pmBAnW17 X-Received: by 10.68.106.100 with SMTP id gt4mr15821241pbb.33.1447988022560; Thu, 19 Nov 2015 18:53:42 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id k10sm13290850pbq.78.2015.11.19.18.53.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Nov 2015 18:53:41 -0800 (PST) To: "Xie, Huawei" , Rich Lane References: <1447930650-26023-1-git-send-email-mukawa@igel.co.jp> <564E86F6.8030904@igel.co.jp> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <564E8B30.4090107@igel.co.jp> Date: Fri, 20 Nov 2015 11:53:36 +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: <564E86F6.8030904@igel.co.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "nakajima.yoshihiro@lab.ntt.co.jp" , "zhbzg@huawei.com" , "mst@redhat.com" , "dev@dpdk.org" , "oscar.zhangbo@huawei.com" , "gaoxiaoqiu@huawei.com" , "ann.zhuangyanying@huawei.com" , "zhoujingbin@huawei.com" , "guohongzhen@huawei.com" Subject: Re: [dpdk-dev] [RFC PATCH 0/2] Virtio-net PMD Extension to work on host. 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: Fri, 20 Nov 2015 02:53:43 -0000 On 2015/11/20 11:35, Tetsuya Mukawa wrote: > On 2015/11/20 11:00, Xie, Huawei wrote: >> On 11/20/2015 2:16 AM, Rich Lane wrote: >>> What's the reason for using qemu as a middleman? Couldn't the new PMD >>> itself open /dev/vhost-net or the vhost-user socket and send the commands >>> to set up virtqueues? That was the approach taken by Jianfeng's earlier RFC. >> Rich: >> Our initial POC also has a device simulation layer, but it is linked >> with the DPDK driver as a library. >> As i created that device simulation based on lkvm, and it takes too much >> effort to rewrite it from scratch, so we decide to release a simple >> version without device simulation first. >> Without device simulation, The PMD is pretty simple, standalone, no >> dependency to qtest process. >> With device simulation, we could easily implement other virtio device in >> DPDK easily, like virtio-crypt. > Hi Rich and Xie, > > Probably, how to prepare virtio-net device is the difference between > Jianfeng's RFC and our RFC. > The reason why I choose this approach is below. > > 1. Ease of maintenance > If we have our virtio-net device, we need to spend time to maintain it. > And QEMU virtio-net code is more tested by more virtio-net drivers and > more users. As a result, it should have less bugs. > Also, If we uses QEMU virtio-net code, we only need to maintain QTest > related implementation. > Anyway, QTest is very stable. > Probably we have bugs first, but later, we don't need to maintain it so > much. > > 2. Extendability > The virtio-net and vhost specification will be extended in the future. > If we have own implementation, we need to maintain more codes. > > >> Maybe anyway we provide the simple implementation option, for customers >> who don't like the extra complexity to launch a secondary process in >> their container. >> [...] >> >> > For example, for the user who is OK to invoke 2 processes in same > container, just prepare shell script that invokes QTest process and > vhost-user backend process will be enough. > > For the users who doesn't want to invoke 2 processes in one container, > anyway they use some kind of orchestration tool, so invoking one more > process/container is not difficult. > > I guess the invoking and connecting multiple processes over containers > may not be something special for container users. > (like deploying load balancer, web server and DB) > > Tetsuya But yes, it may be nice to have option for the users who only needs limited features. Actually, I am not container users, so not sure which is preferred. If we have the option, I guess we need to choose very limited features to be easy to maintain. Thanks, Tetsuya