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 308CC2A58 for ; Wed, 5 Jul 2017 11:30:44 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2DE8F80F94; Wed, 5 Jul 2017 09:30:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2DE8F80F94 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2DE8F80F94 Received: from [10.36.112.37] (ovpn-112-37.ams2.redhat.com [10.36.112.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 63D887E902; Wed, 5 Jul 2017 09:30:39 +0000 (UTC) To: Santosh Shukla , thomas@monjalon.net, bruce.richardson@intel.com, dev@dpdk.org Cc: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com References: <20170608110513.22548-1-santosh.shukla@caviumnetworks.com> From: Maxime Coquelin Message-ID: <59355fcd-0da3-9625-8a0c-dc8c4d44c127@redhat.com> Date: Wed, 5 Jul 2017 11:30:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170608110513.22548-1-santosh.shukla@caviumnetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 05 Jul 2017 09:30:43 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 00/10] Infrastructure to detect iova mapping on the bus 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: Wed, 05 Jul 2017 09:30:44 -0000 On 06/08/2017 01:05 PM, Santosh Shukla wrote: > Q) Why do we need such infrastructure? > > A) Some NPU hardware like OCTEONTX follows push model to get the packet > from the pktio device. Where packet allocation and freeing done > by the HW. Since HW can operate only on IOVA with help of SMMU/IOMMU, > when packet receives from the Ethernet device, it is the IOVA address > (which is PA in existing scheme). > > Mapping IOVA as PA is expensive on those HW, where every packet > needs to be converted to VA from PA/IOVA. > > This patchset proposes the method to autodetect the preferred > IOVA mode for a device. Summary of IOVA scheme: > - If all the devices are iommu capable and support IOMMU > capable driver then selects IOVA_VA. > - If any of the devices are non-iommu then use default IOVA > scheme ie. IOVA_PA. > - If no device found then IOVA scheme would be > IOVA_DC (Don't care). Isn't it possible to have a per-device granularity? For example, with virt case, having a physical NIC using VFIO with iommu, and virtio devices with noiommu. If the physical NIC prefers working with VAs, why forcing it to use PAs? Maybe I missed a limitation though. Cheers, Maxime