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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 050DAC0650E for ; Thu, 4 Jul 2019 09:18:54 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 8FD3B21882 for ; Thu, 4 Jul 2019 09:18:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FD3B21882 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 5C31B1B96B; Thu, 4 Jul 2019 11:18:52 +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 61C7E1B955 for ; Thu, 4 Jul 2019 11:18:51 +0200 (CEST) Received: by mail-ua1-f67.google.com with SMTP id j8so906379uan.6 for ; Thu, 04 Jul 2019 02:18:51 -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=nOzBAjAyQB4iYBdgB5rcwAwBoG0JGaXRXB9kWF5KX68=; b=AgYurh8tHZBd4KTaaltRmtrFeIB7WdRTTvlphMPiDTeZ7aLUhKBAE7tP7+sTuO8GBR c7pBZj2TU4igcNjxG/NFI7PgSsGeNaTa5dvoVASGlsmzfDS84GZN0H/5TYRhDaIEBuaV io6/U9fIQe3GCm5h8vyxTxbHqV2YYjGwno1QXdkhQQxPviavUISubqS1DWkgtYuwBc/x 9jUhthwA4+w0jJB4bqw6hAW1LRExBgW2iN/f6RuigKf2R4y1vo/fI6c3W6FByX7HpYMX /al0z/ev93pFVGk6HMRNW4GoXuVoaY3JNsB7Cc5L9sYy1U625VrjCK3iNjAY2hOJfhrU +hMg== X-Gm-Message-State: APjAAAWFYDs0rWOxOk3dVdhvw83T2lIgHeeNIic03XTAdN4QSuhuOhoq d/4TRF3qJB9H7drDM64j9iR/cj5r/a0h0nDL5B5VUw== X-Google-Smtp-Source: APXvYqxTGSvu/aoay97KnkgCD4P8I1A/wk9dIbUCdTc+/0bjIpIMZTWyMJ1VW+HcZ0o3a1V/ZGNoQh1+qvuONeYs8Fo= X-Received: by 2002:ab0:b99:: with SMTP id c25mr21019243uak.53.1562231930794; Thu, 04 Jul 2019 02:18:50 -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-4-git-send-email-david.marchand@redhat.com> <4fabfd5f-2ba9-ff45-59dd-cfd01b8d49d5@intel.com> In-Reply-To: <4fabfd5f-2ba9-ff45-59dd-cfd01b8d49d5@intel.com> From: David Marchand Date: Thu, 4 Jul 2019 11:18:39 +0200 Message-ID: To: "Burakov, Anatoly" Cc: dev , Ben Walker , Jerin Jacob Kollanukkaran , Maxime Coquelin , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 3/3] bus/pci: only consider usable devices to select IOVA mode 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:45 PM Burakov, Anatoly wrote: > On 14-Jun-19 10:39 AM, David Marchand wrote: > > From: Ben Walker > > > > When selecting the preferred IOVA mode of the pci bus, the current > > heuristic ("are devices bound?", "are devices bound to UIO?", "are pmd > > drivers supporting IOVA as VA?" etc..) should honor the device > > white/blacklist so that an unwanted device does not impact the decision. > > > > There is no reason to consider a device which has no driver available. > > > > This applies to all OS, so implements this in common code then call a > > OS specific callback. > > > > On Linux side: > > - the VFIO special considerations should be evaluated only if VFIO > > support is built, > > - there is no strong requirement on using VA rather than PA if a driver > > supports VA, so defaulting to DC in such a case. > > > > Signed-off-by: Ben Walker > > Signed-off-by: David Marchand > > --- > > > > > + const struct rte_pci_device *pdev) > > { > > - struct rte_pci_device *dev = NULL; > > - struct rte_pci_driver *drv = NULL; > > + enum rte_iova_mode iova_mode = RTE_IOVA_DC; > > + static int iommu_no_va = -1; > > > > - FOREACH_DRIVER_ON_PCIBUS(drv) { > > - FOREACH_DEVICE_ON_PCIBUS(dev) { > > - if (!rte_pci_match(drv, dev)) > > - continue; > > - /* > > - * just one PCI device needs to be checked out > because > > - * the IOMMU hardware is the same for all of them. > > - */ > > - return pci_one_device_iommu_support_va(dev); > > + switch (pdev->kdrv) { > > + case RTE_KDRV_VFIO: { > > +#ifdef VFIO_PRESENT > > + static int is_vfio_noiommu_enabled = -1; > > + > > + if (is_vfio_noiommu_enabled == -1) { > > + if (rte_vfio_noiommu_is_enabled() == 1) > > + is_vfio_noiommu_enabled = 1; > > + else > > + is_vfio_noiommu_enabled = 0; > > + } > > + if ((pdrv->drv_flags & RTE_PCI_DRV_IOVA_AS_VA) == 0) { > > + iova_mode = RTE_IOVA_PA; > > + } else if (is_vfio_noiommu_enabled != 0) { > > + RTE_LOG(DEBUG, EAL, "Forcing to 'PA', vfio-noiommu > mode configured\n"); > > + iova_mode = RTE_IOVA_PA; > > } > > +#endif > > + break; > > I'm not too well-versed in bus code, so please excuse my ignorance of > this codebase. > > It seems that we would be ignoring drv_flags in case VFIO wasn't > compiled - if the driver has no RTE_PCI_DRV_IOVA_AS_VA flag, i'm pretty > sure we can set IOVA mode to PA without caring about VFIO at all. I > think it would be better to have something like this: > > if ((pdrv->drv_flags & RTE_PCI_DRV_IOVA_AS_VA) == 0) { > iova_mode = RTE_IOVA_PA; > break; // early exit > } > If the device is bound to VFIO, but the dpdk binary has no vfio support, we don't need to consider this device in the decision. Did I miss something in what you suggest? -- David Marchand