From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 56F809430 for ; Wed, 6 Jan 2016 06:42:44 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 05 Jan 2016 21:42:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,527,1444719600"; d="scan'208";a="875436321" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.119]) ([10.239.67.119]) by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2016 21:42:43 -0800 To: Tetsuya Mukawa , "dev@dpdk.org" References: <1447930650-26023-2-git-send-email-mukawa@igel.co.jp> <1450255049-2263-1-git-send-email-mukawa@igel.co.jp> <568117AB.1080605@igel.co.jp> <568C90A7.9040503@igel.co.jp> From: "Tan, Jianfeng" Message-ID: <568CA950.9000205@intel.com> Date: Wed, 6 Jan 2016 13:42:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568C90A7.9040503@igel.co.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "nakajima.yoshihiro@lab.ntt.co.jp" , "mst@redhat.com" Subject: Re: [dpdk-dev] [PATCH v1 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: Wed, 06 Jan 2016 05:42:44 -0000 On 1/6/2016 11:57 AM, Tetsuya Mukawa wrote: > On 2015/12/28 20:06, Tetsuya Mukawa wrote: >> On 2015/12/24 23:05, Tan, Jianfeng wrote: >>> Hi Tetsuya, >>> >>> After several days' studying your patch, I have some questions as follows: >>> >>> 1. Is physically-contig memory really necessary? >>> This is a too strong requirement IMHO. IVSHMEM doesn't require this in its original meaning. So how do you think of >>> Huawei Xie's idea of using virtual address for address translation? (In addition, virtual address of mem_table could be >>> different in application and QTest, but this can be addressed because SET_MEM_TABLE msg will be intercepted by >>> QTest) >> Hi Jianfeng, >> >> Thanks for your suggestion. >> Huawei's idea may solve contig-mem restriction. >> Let me have time to check it more. > Hi Jianfeng, > > I made sure we can remove the restriction with Huawei's idea. > One thing I concern is below. > If we don't use contiguous memory, this PMD will not work with other > 'physical' PMDs like e1000 PMD, virtio-net PMD, and etc. > (This is because allocated memory may not be physically contiguous.) > > One of examples is that if we implement like above, in QEMU guest, we > can handle a host NIC directly, but in container, we will not be able to > handle the device. > This will be a restriction for this virtual addressing changing. > > Do you know an use case that the user wants to handle 'physical' PMD and > 'virtual' virtio-net PMD together? > > Tetsuya, Hi Tetsuya, I have no use case in hand, which handles 'physical' PMDs and 'virtual' virtio-net PMD together. (Pavel Fedin once tried to run ovs in container, but that case just uses virtual virtio devices, I don't know if he has plan to add 'physical' PMDs as well.) Actually, it's not completely contradictory to make them work together. Like this: a. containers with root privilege We can initialize memory as legacy way. (TODO: besides physical-contiguous, we try allocate virtual-contiguous big area for all memsegs as well.) a.1 For vhost-net, before sending memory regions into kernel, we can merge those virtual-contiguous regions into one region. a.2 For vhost-user, we can merge memory regions in the vhost. The blocker is that for now, maximum fd num was restricted by VHOST_MEMORY_MAX_NREGIONS=8 (so in 2M-hugepage's case, 16M shared memory is not nearly enough). b. containers without root privilege No need to worry about this problem, because it lacks of privilege to construct physical-contiguous memory. Thanks, Jianfeng