From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by dpdk.org (Postfix) with ESMTP id A13B19585 for ; Wed, 6 Jan 2016 08:34:59 +0100 (CET) Received: by mail-pa0-f46.google.com with SMTP id cy9so229174044pac.0 for ; Tue, 05 Jan 2016 23:34:59 -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=maNCELcvkCWJOYVzqGe6B/FS0lb8LRQ/Fvx8SCvrtqo=; b=X9DrOLieL7p+VwOaJA2Nye/R8X8Av1cQwfypgFOvVwYUGgxqdjFfp9cqSSmExDuobM KAyw3ijEi8VktCZEKDDBYQj4xPt5S6PMoYVL7KGImFtbaAJ2F9eNMWTL145himmB/MAg gd1j2ez71+UK+pZxEbMFpU0llrpB6ENLWBdNWt4QUrYyiKks7IdSwVMX8gV06o2BTz4j /7h3FN3jz5pwPLntEjnbsRp0Asd6TjI00B0WJaGsk/wemfiYORrzSjsp8OS2gcXYLy08 qh5UcRudNH9PBpjDLeYay0DxtN33Bl5Tm8POvGNvs1yMqdp6IwGctJFaW3CiB2FGzJdx NLgQ== 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=maNCELcvkCWJOYVzqGe6B/FS0lb8LRQ/Fvx8SCvrtqo=; b=fFLqIcCyHyBE33OLSobMOZMMZQ27ROW1at/vaX7YAWEqBlzhup8iFDEdaZzO0Cf2G2 4hUD3iTCnDrR16pFXGS/0OcMW91ysAWwUmq2q5TvwKmI6DvjIsGqrH2tSmJgNrikoYTC Mxke/6s4AEiidDeopvqejznBwEFA9NMKblSXEAIqAJIkE7yUBv1OPrrzYoZQsGS5ECsh EZ0d2kxysSMgk2m6Z46PIgzPvmhLeV6aQVye6eIG7iKEO8n6T2Lvoq3YYMqTpculGDRh nEJNpmaiQwh5Wqgr9rpNCb6zEdKjBUtYntqAM4cMVFy/KRw8Eqnmqh9TMC8In5krbeAG Uvlw== X-Gm-Message-State: ALoCoQlYxfJ00uUuIlOLXi+SXgOEDUbe34oiq5qpK9XNX0m19JWgxOQDjLobe3FfjZ5pQccwJsviwLttXX8gtQtkrSLXsElijQ== X-Received: by 10.66.251.3 with SMTP id zg3mr140508433pac.145.1452065698915; Tue, 05 Jan 2016 23:34:58 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id fc6sm138273398pac.44.2016.01.05.23.34.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jan 2016 23:34:58 -0800 (PST) To: "Tan, Jianfeng" , "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> <568CA950.9000205@intel.com> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <568CC3A4.7080603@igel.co.jp> Date: Wed, 6 Jan 2016 16:35:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568CA950.9000205@intel.com> Content-Type: text/plain; charset=windows-1252 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 07:35:00 -0000 On 2016/01/06 14:42, Tan, Jianfeng wrote: > > > 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.) Hi Jianfeng, Yes, I agree with you. If the feature is really needed, we will be able to have work around. > > 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). > With current your implementation, when 'virtual' virtio-net PMD is used, 'phys_addr' will be virtual address in EAL layer. struct rte_memseg { phys_addr_t phys_addr; /**< Start physical address. */ union { void *addr; /**< Start virtual address. */ uint64_t addr_64; /**< Makes sure addr is always 64 bits */ }; ....... }; How about choosing it in virtio-net PMD? (In the case of 'virtual', just use 'addr' instead of using 'phys_addr'.) For example, port0 may use physical address, but port1 may use virtual address. With this, of course, we don't have an issue with 'physical' virtio-net PMD. Also, with 'virtual' virtio-net PMD, we can use virtual address and fd that represents the big virtual address space. (TODO: Need to change rte_memseg and EAL to keep fd and offset?) Then, you don't worry about VHOST_MEMORY_MAX_NREGIONS, because we have only one fd. > b. containers without root privilege > No need to worry about this problem, because it lacks of privilege to > construct physical-contiguous memory. > Yes, we cannot run 'physical' PMDs in this type of container. Anyway, I will check it more, if we really need it. Thanks, Tetsuya