From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id BA6761B168 for ; Fri, 5 Jan 2018 13:04:12 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DDFD3780D8; Fri, 5 Jan 2018 12:04:11 +0000 (UTC) Received: from [10.36.112.27] (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 10EAE5C542; Fri, 5 Jan 2018 12:04:04 +0000 (UTC) From: Maxime Coquelin To: Jianfeng Tan , dev@dpdk.org, santosh.shukla@caviumnetworks.com, ferruh.yigit@intel.com Cc: sergio.gonzalez.monroy@intel.com, thomas@monjalon.net, Peter Xu References: <1507718028-12943-1-git-send-email-jianfeng.tan@intel.com> <1507718028-12943-3-git-send-email-jianfeng.tan@intel.com> <6367d190-5d4b-71c1-5790-3b488f4dcc18@redhat.com> Message-ID: Date: Fri, 5 Jan 2018 13:04:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6367d190-5d4b-71c1-5790-3b488f4dcc18@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 05 Jan 2018 12:04:12 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 2/2] net: enable IOVA mode for PMDs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 12:04:13 -0000 On 01/05/2018 11:32 AM, Maxime Coquelin wrote: > Hi Jianfeng, > > On 10/11/2017 12:33 PM, Jianfeng Tan wrote: >> If we want to enable IOVA mode, introduced by >> commit 93878cf0255e ("eal: introduce helper API for IOVA mode"), >> we need PMDs (for PCI devices) to expose this flag. >> >> Signed-off-by: Jianfeng Tan >> --- >>   drivers/net/e1000/em_ethdev.c     | 3 ++- >>   drivers/net/e1000/igb_ethdev.c    | 5 +++-- >>   drivers/net/fm10k/fm10k_ethdev.c  | 3 ++- >>   drivers/net/i40e/i40e_ethdev.c    | 3 ++- >>   drivers/net/i40e/i40e_ethdev_vf.c | 2 +- >>   drivers/net/ixgbe/ixgbe_ethdev.c  | 5 +++-- >>   6 files changed, 13 insertions(+), 8 deletions(-) > > This patch introduces a regression when doing device assignment in > guest, because current VT-d emulation only supports 39bits guest address > width [0]. > > In the Bz, Peter suggest we could have an IOVA allocator algorithm, > which could start to allocate IOVAs from 0. I think it could solve the > --no-huge case your series address, do you agree? > > But it would be a long term solution, we need to fix this in stable. > > Is the --no-huge option used in production, or is it only for testing? > If the latter do you think we could revert your patch while we find a > solution that makes all cases to work? It seems that we can get Intel IOMMU's Guest Address Width from the sysfs, as the CAP register is exposed. So we can get the SAGAW value (see [1], page 217): On Bare Metal: # echo $(((0x`cat /sys/class/iommu/dmar0/intel-iommu/cap` >> 8) & 0x1f)) 4 => 48bits In guest: # echo $(((0x`cat /sys/class/iommu/dmar0/intel-iommu/cap` >> 8) & 0x1f)) 2 => 39bits Using this, we could or not allow the VA mode when using Intel IOMMU. Any thoughts? Regards, Maxime [1]: https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf > Ferruh, I see you also faced problems with KNI, how did you solved it? > > Thanks, > Maxime > > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1530957#c3