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 C33CAA00BE; Tue, 28 Apr 2020 10:51:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75C021D588; Tue, 28 Apr 2020 10:51:06 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 64EEA1D57F for ; Tue, 28 Apr 2020 10:51:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588063864; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1tGMVByMsLIsnU9fg9IuS7LcCneqZAeypF4k+G8a45g=; b=P9TQhyUSPwsY1LuZPWyRbEaRjqqyKBkMHH5bVRXxZn9EqhrO/WvHwAA/Pn3vWaiC4YBx7P kngWGR881XH2fvn857lhxNv5JbE4flrP0smOwr9ZFXvGgN2HW2sf3YlRcseg+myNI2b5OL 3FaQvd6bdCwiK4T13RXp4Ov1bhKMXF4= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-91-bZsU5w8rNfedwbxhec0_bg-1; Tue, 28 Apr 2020 04:51:00 -0400 X-MC-Unique: bZsU5w8rNfedwbxhec0_bg-1 Received: by mail-vk1-f197.google.com with SMTP id w25so10408445vkm.8 for ; Tue, 28 Apr 2020 01:51:00 -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=iG6L11zI0ULdR4NpJZ8lxfkRdlLlJ+O2Q73rA1c6yGE=; b=bNK2CwHRQYkYqNtyzPs5oUm3bOSWui9xsnyLXMLYHFG4ssLyiSeRXnVFbETKUXCSdu I391zeOaruW2FlQcTbMLYxMs7K6CapHzyzc+JAGETlT4gV++rBOfkycFt3uzFOHcIWw0 QvL6ngw2sMuGnnBzZDo8/B4nyg2G899wv6fgc7+Ek9JmnHuojNqcgxUJ12IXVsBZ5ylE pIQRobpOhJvQFOB6RodGACTlfxg7KDZsC7UtImKGLWxwgEpgCJQFd2NDM/TsIXC7DeSJ 88oQ4gnp+AiuVkU3xoOfimuT1n1vLh8P20ShG/tdheRwo4gL22HEmwmqGKgRnhd6rd2J tn3Q== X-Gm-Message-State: AGi0PuYWlZEDfAcOa8pHxWiQEJ+TJiBi/o3QVGli9KfcoKVX1IKYE2qj tl1dE2XeH6RwpoCBC+cgEEgHNId+Tl5dNrvYWtAJ6MAwoNNGsJ4VsILNJG/fgp1D/NLSkp1gue9 l6NcoZVorFu6eusOmxpg= X-Received: by 2002:ab0:5586:: with SMTP id v6mr17633570uaa.87.1588063860150; Tue, 28 Apr 2020 01:51:00 -0700 (PDT) X-Google-Smtp-Source: APiQypLhLw/oudOtVmNbZclrGk/rtudtf8KdxycASaVplWohz21LM/7DXbSZD6Qmc5JlIcOlNmc8XXk9orwsuyzReyk= X-Received: by 2002:ab0:5586:: with SMTP id v6mr17633558uaa.87.1588063859858; Tue, 28 Apr 2020 01:50:59 -0700 (PDT) MIME-Version: 1.0 References: <20200426173811.49788-1-jerinj@marvell.com> <3102527.CAdn2TfLgq@thomas> <6277521.uz5P2jW1tq@thomas> In-Reply-To: <6277521.uz5P2jW1tq@thomas> From: David Marchand Date: Tue, 28 Apr 2020 10:50:48 +0200 Message-ID: To: Thomas Monjalon Cc: Jerin Jacob , Jerin Jacob , dpdk-dev , Maxime Coquelin , Zhihong Wang , "Ye, Xiaolong" , Harman Kalra X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] bus/pci: optimize pci device probe 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 Sun, Apr 26, 2020 at 10:06 PM Thomas Monjalon wrot= e: > > 26/04/2020 20:41, Jerin Jacob: > > On Sun, Apr 26, 2020 at 11:38 PM Thomas Monjalon = wrote: > > > > > > 26/04/2020 19:38, jerinj@marvell.com: > > > > From: Jerin Jacob > > > > > > > > If the PCI device is not attached to any driver then there is no > > > > point in probing it. As an optimization, skip the PCI device probe = if > > > > the PCI device driver of type RTE_KDRV_NONE. > > > > > > > > Signed-off-by: Jerin Jacob > > > > --- > > > > Notes: > > > > ------ > > > > - virtio drivers does special treatment based on RTE_KDRV_UNKNOWN, = That is > > > > the reason allowing RTE_KDRV_UNKNOWN in this patch. > > > > - virio devices uses RTE_KDRV_UNKNOWN for some special meaning, IMO= , if it would > > > > be better, if > > > > a) Introduce the KDRV for virio > > > > b) If the PCIe device of driver type NONE or UNKNOWN then not even = add in pci > > > > list > > > > in the scan, It will improve the boot time by avoiding operation on > > > > unwanted device like sorting the PCI devices, scanning it, probe it= , managing > > > > it etc. > > > > > > mlx4/mlx4 uses RTE_KDRV_UNKNOWN. > > > > OK. > > > > > > - Initial problem reported at http://patches.dpdk.org/patch/64999/ = as > > > > boot time printf clutter on octeontx2 devices with a lot PCI device= s which are > > > > of type RTE_KDRV_NONE. > > > > > > Add a logtype for PCI driver and adjust log level accordingly > > > to your preferences. > > > > > > > @@ -271,6 +271,8 @@ pci_probe_all_drivers(struct rte_pci_device *de= v) > > > > FOREACH_DRIVER_ON_PCIBUS(dr) { > > > > + if (dev->kdrv =3D=3D RTE_KDRV_NONE) > > > > + continue; > > > > rc =3D rte_pci_probe_one_driver(dr, dev); > > > > > > Nack > > > > I understand mlx4/mlx5 is using RTE_KDRV_UNKNOWN, Here we are skipping > > the RTE_KDRV_NONE, > > What is the use case for probing the devices with RTE_KDRV_NONE? > > Maybe you are right. I don't remember the use case. > I think I remember these virtio and vmxnet3 PMD were not using UIO: > http://git.dpdk.org/old/virtio-net-pmd/tree/virtio_user.c > http://git.dpdk.org/old/vmxnet3-usermap/tree/pmd/vmxnet3.c > > We need to know which case is using following code: > > case RTE_KDRV_NONE: > #if defined(RTE_ARCH_X86) > ret =3D pci_ioport_map(dev, bar, p); > #endif > break; > > David, please could you refresh our memory? The in-tree virtio-net driver directly calls rte_pci_map_device / rte_pci_ioport_map depending on virtio legacy/modern modes. This is why the virtio pci driver does not ask for RTE_PCI_DRV_NEED_MAPPING to the pci bus. In ioport mode, there were two options for historical reasons because of the virtio driver you mention. This driver did not rely on uio, and this behavior was later merged to the current in-tree driver. It ended up (not clean) in the pci bus driver because virtio was the only user of this code. Removing this special case could break x86 applications running with legacy virtio. On the plus side, we have been announcing for some time in virtio: RTE_PMD_REGISTER_KMOD_DEP(net_virtio, "* igb_uio | uio_pci_generic | vfio-p= ci"); --=20 David Marchand