From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by dpdk.org (Postfix) with ESMTP id 1F6EC5913 for ; Fri, 22 Jan 2016 11:37:17 +0100 (CET) Received: by mail-pa0-f54.google.com with SMTP id uo6so40585949pac.1 for ; Fri, 22 Jan 2016 02:37:17 -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=psczUwLxM45fNbnAGOL3J7qYL9arN3XYLnWwYYCgRE8=; b=nvb7B6e4Uu79ZXRAOaach2kAQytNmrLHBPZ53cHTbgOEOq5HYeZAZACcV5YdXmqblW lOg5uPER0LNhnqOYTalFUto+/BK+CV/KJ1VD6p1ZSNDxuQXpsx0vIvRkTs84TGLjo5d4 S9Fr0rG77S6fCuCme73GdszuDg6v652W9w6bGUHNtegjMkhJd+kKukffnqT/XFbZItpH mCbxobXVuBupTEyXvxiCXRLDR/agjzBssvopXEWF01BjtTF33MJu2ruT0Bqz9AbIUpav hFPcyVyAuS+I2uOeMpHZeaRSC1HG+6daF3jgX+il87Ok09GhSiD2zNsYdUQ/fRbuTdnt 3NlA== 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=psczUwLxM45fNbnAGOL3J7qYL9arN3XYLnWwYYCgRE8=; b=DnSOshd5qZ2p+qLWwdpsBxXQIAlXM2R2fziKr9PUtnrNlv25ECJNiOGtCubi3wy/Lk Nrlf6sNnYUCI303FPFfTJ4J+83rBK1MWJW3TRZvLx52IxLjmCdDz0CceY95FxPIMNCe1 EobS/RWD1ddT0tX0hblwPyblQZyoSO9IdlDSFHJUAYZCAUXJbeQT43tKMqVo1nJfC36K dW870FnxMwDBSfaxZHkbHU5J5p9nzM1tiCQpbr3nCV2zHSXCykvjWyFHUZv67LXhOzu8 fBSOih8s2IiHM8qSVb2A1c9EPcg0zt9hDMlfRp/G9m3R9ph3++XkwnED9JJlv8jTl0rG u0HQ== X-Gm-Message-State: AG10YOQB4EvbR+htBKYuDj8vXOQec8RYbFS78kx8eR3MwlIu+O1CZJErg8W1pgfUxvKcEw== X-Received: by 10.66.150.202 with SMTP id uk10mr3242971pab.73.1453459035625; Fri, 22 Jan 2016 02:37:15 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id 7sm8701510pfn.89.2016.01.22.02.37.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 02:37:14 -0800 (PST) To: "Xie, Huawei" , "dev@dpdk.org" , "yuanhan.liu@linux.intel.com" , "Tan, Jianfeng" References: <1453108389-21006-2-git-send-email-mukawa@igel.co.jp> <1453374478-30996-6-git-send-email-mukawa@igel.co.jp> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <56A2065A.9020207@igel.co.jp> Date: Fri, 22 Jan 2016 19:37:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC PATCH 5/5] virtio: Extend virtio-net PMD to support container environment 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, 22 Jan 2016 10:37:17 -0000 On 2016/01/22 17:14, Xie, Huawei wrote: > On 1/21/2016 7:09 PM, Tetsuya Mukawa wrote: >> virtio: Extend virtio-net PMD to support container environment >> >> The patch adds a new virtio-net PMD configuration that allows the PMD to >> work on host as if the PMD is in VM. >> Here is new configuration for virtio-net PMD. >> - CONFIG_RTE_LIBRTE_VIRTIO_HOST_MODE >> To use this mode, EAL needs physically contiguous memory. To allocate >> such memory, add "--shm" option to application command line. >> >> To prepare virtio-net device on host, the users need to invoke QEMU >> process in special qtest mode. This mode is mainly used for testing QEMU >> devices from outer process. In this mode, no guest runs. >> Here is QEMU command line. >> >> $ qemu-system-x86_64 \ >> -machine pc-i440fx-1.4,accel=qtest \ >> -display none -qtest-log /dev/null \ >> -qtest unix:/tmp/socket,server \ >> -netdev type=tap,script=/etc/qemu-ifup,id=net0,queues=1\ >> -device virtio-net-pci,netdev=net0,mq=on \ >> -chardev socket,id=chr1,path=/tmp/ivshmem,server \ >> -device ivshmem,size=1G,chardev=chr1,vectors=1 >> >> * QEMU process is needed per port. > Does qtest supports hot plug virtio-net pci device, so that we could run > one QEMU process in host, which provisions the virtio-net virtual > devices for the container? Theoretically, we can use hot plug in some cases. But I guess we have 3 concerns here. 1. Security. If we share QEMU process between multiple DPDK applications, this QEMU process will have all fds of the applications on different containers. In some cases, it will be security concern. So, I guess we need to support current 1:1 configuration at least. 2. shared memory. Currently, QEMU and DPDK application will map shared memory using same virtual address. So if multiple DPDK application connects to one QEMU process, each DPDK application should have different address for shared memory. I guess this will be a big limitation. 3. PCI bridge. So far, QEMU has one PCI bridge, so we can connect almost 10 PCI devices to QEMU. (I forget correct number, but it's almost 10, because some slots are reserved by QEMU) A DPDK application needs both virtio-net and ivshmem device, so I guess almost 5 DPDK applications can connect to one QEMU process, so far. To add more PCI bridges solves this. But we need to add a lot of implementation to support cascaded PCI bridges and PCI devices. (Also we need to solve above "2nd" concern.) Anyway, if we use virtio-net PMD and vhost-user PMD, QEMU process will not do anything after initialization. (QEMU will try to read a qtest socket, then be stopped because there is no message after initialization) So I guess we can ignore overhead of these QEMU processes. If someone cannot ignore it, I guess this is the one of cases that it's nice to use your light weight container implementation. Thanks, Tetsuya