From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4C13AA0487 for ; Thu, 4 Jul 2019 09:13:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D58075B3A; Thu, 4 Jul 2019 09:13:18 +0200 (CEST) Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com [209.85.222.67]) by dpdk.org (Postfix) with ESMTP id 4C00D5B34 for ; Thu, 4 Jul 2019 09:13:17 +0200 (CEST) Received: by mail-ua1-f67.google.com with SMTP id z13so792904uaa.4 for ; Thu, 04 Jul 2019 00:13:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gLO028r68SRa6hKKGRUJ8BDasNCk6tVOdpxdiTdr8u0=; b=cclWn+8gMQlKoPBOM3MIpUCp3YPWW5WueEQy8x4gQiByhaW63/g9tW2uM72f6Zay+y Rq9qUihIf7vhmkm1hdb+MDJTZQwU/Zz2fhapbyvr21GZ5ZqRzPM9FZC029PUih4PuCWO YgeWZ0Nmm89TiqJmN8Yf7dje/JVEaFzCpEYZlK3DuwrJQ+0g0EJBWWyBWwkVUn6vCW3Q ueTj0JiYCH1Mtsc7zl5hVTqVEzpDKf+G0uACv62aQw0H2G1D1qEITKBDxbeSyMB7ubuY AGSCXXumqNYZnqhv6jyez0IkAVeqI9PMSqhB1cK+SuXxz13AABGpcsjJvqWL5qbEVMVd NoGg== X-Gm-Message-State: APjAAAXn3Gk64VE/2HrF+IRKJFKiE12toS2F+otuWzQyzNIdEIkgR3Qa ppVT685ris2CbTAW/5ByaVf/aAfBFJaEjSL4nbDndg== X-Google-Smtp-Source: APXvYqyfOyV3HpHGi7IXDz1622JbYDCIhMk1vuhBcvzq5fhQBbuOqbbbsYyVmd37/EHW4UCeoz2XzIvRcPTxp00qfz4= X-Received: by 2002:ab0:168a:: with SMTP id e10mr20390496uaf.87.1562224396689; Thu, 04 Jul 2019 00:13:16 -0700 (PDT) MIME-Version: 1.0 References: <20190530174819.1160221-1-benjamin.walker@intel.com> <1560505157-9769-1-git-send-email-david.marchand@redhat.com> <1560505157-9769-3-git-send-email-david.marchand@redhat.com> <1cc18fa3-8ea7-e980-2007-e9a68d0a3f39@intel.com> In-Reply-To: <1cc18fa3-8ea7-e980-2007-e9a68d0a3f39@intel.com> From: David Marchand Date: Thu, 4 Jul 2019 09:13:05 +0200 Message-ID: To: "Burakov, Anatoly" Cc: dev , Ben Walker , Jerin Jacob Kollanukkaran , Maxime Coquelin , Thomas Monjalon , Bruce Richardson Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: compute IOVA mode based on PA availability 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" On Wed, Jul 3, 2019 at 12:17 PM Burakov, Anatoly wrote: > On 14-Jun-19 10:39 AM, David Marchand wrote: > > From: Ben Walker > > > > Currently, if the bus selects IOVA as PA, the memory init can fail when > > lacking access to physical addresses. > > This can be quite hard for normal users to understand what is wrong > > since this is the default behavior. > > > > Catch this situation earlier in eal init by validating physical addresses > > availability, or select IOVA when no clear preferrence had been > expressed. > > > > The bus code is changed so that it reports when it does not care about > > the IOVA mode and let the eal init decide. > > > > In Linux implementation, rework rte_eal_using_phys_addrs() so that it can > > be called earlier but still avoid a circular dependency with > > rte_mem_virt2phys(). > > In FreeBSD implementation, rte_eal_using_phys_addrs() always returns > > false, so the detection part is left as is. > > > > If librte_kni is compiled in and the KNI kmod is loaded, > > - if the buses requested VA, force to PA if physical addresses are > > available as it was done before, > > - else, keep iova as VA, KNI init will fail later. > > > > Signed-off-by: Ben Walker > > Signed-off-by: David Marchand > > --- > > > > > + /* autodetect the IOVA mapping mode */ > > + 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"); > > + } > > +#ifdef RTE_LIBRTE_KNI > > /* Workaround for KNI which requires physical address to > work */ > > - if (rte_eal_get_configuration()->iova_mode == RTE_IOVA_VA > && > > + if (iova_mode == RTE_IOVA_VA && > > rte_eal_check_module("rte_kni") == 1) { > > - rte_eal_get_configuration()->iova_mode = > RTE_IOVA_PA; > > - RTE_LOG(WARNING, EAL, > > - "Some devices want IOVA as VA but PA will > be used because.. " > > - "KNI module inserted\n"); > > + if (phys_addrs) { > > + iova_mode = RTE_IOVA_PA; > > + RTE_LOG(WARNING, EAL, "Forcing IOVA as > 'PA' because KNI module is loaded\n"); > > + } else { > > + RTE_LOG(DEBUG, EAL, "KNI can not work > since physical addresses are unavailable\n"); > > + } > > } > > +#endif > > Why the ifdefs? I don't think there's something specific to KNI there, > rte_eal_check_module() works absent of KNI. > The sole presence of the kni kmod does not mean you have librte_kni in your binary. So if you consider the case where you would have two dpdk applications running, one with kni, the other one without it. It does not makes sense to force PA for the one that does not have librte_kni. Otherwise LGTM, > > Acked-by: Anatoly Burakov > Thanks for the review ! -- David Marchand