From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A4B3C76190 for ; Mon, 22 Jul 2019 12:57:49 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id CCF4721921 for ; Mon, 22 Jul 2019 12:57:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCF4721921 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2C67F1BF99; Mon, 22 Jul 2019 14:57:31 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id A5CCC1BF8E for ; Mon, 22 Jul 2019 14:57:26 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D7C73DBC5; Mon, 22 Jul 2019 12:57:26 +0000 (UTC) Received: from dmarchan.remote.csb (ovpn-204-177.brq.redhat.com [10.40.204.177]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5DD2061377; Mon, 22 Jul 2019 12:57:24 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: anatoly.burakov@intel.com, jerinj@marvell.com, thomas@monjalon.net, John McNamara , Marko Kovacevic Date: Mon, 22 Jul 2019 14:56:53 +0200 Message-Id: <1563800213-29839-5-git-send-email-david.marchand@redhat.com> In-Reply-To: <1563800213-29839-1-git-send-email-david.marchand@redhat.com> References: <1562795329-16652-1-git-send-email-david.marchand@redhat.com> <1563800213-29839-1-git-send-email-david.marchand@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 22 Jul 2019 12:57:26 +0000 (UTC) Subject: [dpdk-dev] [PATCH v4 4/4] eal: select IOVA as VA mode for default case 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Jerin Jacob When bus layer reports the preferred mode as RTE_IOVA_DC then select the RTE_IOVA_VA mode: - All drivers work in RTE_IOVA_VA mode, irrespective of physical address availability. - By default, a mempool asks for IOVA-contiguous memory using RTE_MEMZONE_IOVA_CONTIG. This is slow in RTE_IOVA_PA mode and it may affect the application boot time. Signed-off-by: Jerin Jacob Acked-by: Anatoly Burakov Signed-off-by: David Marchand --- Changelog since v3: - moved the explanations on RTE_IOVA_VA choice in the note section, - reworded the comments on the PCI driver flag, --- doc/guides/prog_guide/env_abstraction_layer.rst | 22 ++++++++++++++++++++-- lib/librte_eal/linux/eal/eal.c | 6 ++---- 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index 1d63675..1487ea5 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -445,11 +445,29 @@ kernels. - if the preferred mode is RTE_IOVA_PA but there is no access to Physical Addresses, then EAL init fails early, since later probing of the devices would fail anyway, -- if the preferred mode is RTE_IOVA_DC then based on the Physical Addresses - availability, the preferred mode is adjusted to RTE_IOVA_PA or RTE_IOVA_VA. +- if the preferred mode is RTE_IOVA_DC then EAL selects the RTE_IOVA_VA mode. In the case when the buses had disagreed on the IOVA Mode at the first step, part of the buses won't work because of this decision. +.. note:: + + The RTE_IOVA_VA mode is selected as the default for the following reasons: + + - All drivers are expected to work in RTE_IOVA_VA mode, irrespective of + physical address availability. + - By default, the mempool, first asks for IOVA-contiguous memory using + ``RTE_MEMZONE_IOVA_CONTIG``. This is slow in RTE_IOVA_PA mode and it may + affect the application boot time. + - It is easy to enable large amount of IOVA-contiguous memory use-cases + with IOVA in VA mode. + + It is expected that all PCI drivers work in both RTE_IOVA_PA and + RTE_IOVA_VA modes. + + If a PCI driver does not support RTE_IOVA_PA mode, the + ``RTE_PCI_DRV_NEED_IOVA_AS_VA`` flag is used to dictate that this PCI + driver can only work in RTE_IOVA_VA mode. + IOVA Mode Configuration ~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c index 2e5499f..34db787 100644 --- a/lib/librte_eal/linux/eal/eal.c +++ b/lib/librte_eal/linux/eal/eal.c @@ -1061,10 +1061,8 @@ static void rte_eal_init_alert(const char *msg) enum rte_iova_mode iova_mode = rte_bus_get_iommu_class(); if (iova_mode == RTE_IOVA_DC) { - iova_mode = phys_addrs ? RTE_IOVA_PA : RTE_IOVA_VA; - RTE_LOG(DEBUG, EAL, - "Buses did not request a specific IOVA mode, using '%s' based on physical addresses availability.\n", - phys_addrs ? "PA" : "VA"); + iova_mode = RTE_IOVA_VA; + RTE_LOG(DEBUG, EAL, "Buses did not request a specific IOVA mode, select IOVA as VA mode.\n"); } #ifdef RTE_LIBRTE_KNI /* Workaround for KNI which requires physical address to work */ -- 1.8.3.1