From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tetsuya Mukawa Subject: Re: [RFC PATCH 0/2] Virtio-net PMD Extension to work on host. Date: Fri, 20 Nov 2015 11:53:36 +0900 Message-ID: <564E8B30.4090107@igel.co.jp> References: <1447930650-26023-1-git-send-email-mukawa@igel.co.jp> <564E86F6.8030904@igel.co.jp> Mime-Version: 1.0 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" To: "Xie, Huawei" , Rich Lane 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) In-Reply-To: <564E86F6.8030904@igel.co.jp> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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