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 5036FA00BE; Sun, 26 Apr 2020 22:06:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B1F851C1A1; Sun, 26 Apr 2020 22:06:08 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id A90931C1A0 for ; Sun, 26 Apr 2020 22:06:07 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5861356E; Sun, 26 Apr 2020 16:06:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 26 Apr 2020 16:06:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= odmPinbhnyogdFAoZLE1qXlONOEaBcfyc73Whnasqwk=; b=bDej9YJnav0JYEEg vyQnmm5XGUJ7Wuq6Sjpks2yOKjYp1I/8WBGf1o4DyfEEnJ+lypliWWGNxl0pZXll +dFW1UrXy1Q2gmVd/cpHCgTxc4YVuit+KqHa8MX9Zfx2fZ8yMgbWE9NoktBy24OT dRswIMby3B9uFfAdtL+kDPOIaBnbZjARHGOEni0IKhLT/GOa+ZuBT5w334D1dwYH xqq83SXf/vIqVXXdAnPAxmHLKt9p/LunEqU+pMCdiIr4PfOD7HpQr2SbrR92lkzP irkv2ob9R6Z5ANqeghzb719yVqtQrfzIM9NC3hBX8byP5U8FqQo9pfRAk7Hx9ZGF xMxtSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=odmPinbhnyogdFAoZLE1qXlONOEaBcfyc73Whnasq wk=; b=RfnaOpCWSp32F0kXt72AKK9hJ1gz4B3xUDgVP62WzNuGvlDqUb/dw9ofR 9uOkaocQtOv+qxfA7vb3wEQU9M057rWl3pda3FYISrASvMiVeVct5Uu0iUivVrC6 O4ZRkwiV0Lp3C6OEC/f9PusZpX3FI0HScyESinxF14cYjbbY7K50EWsXL3XQacPR w7iKP4bIrrRy6wwQjaUG9/to67It+Z3hOECe97oZ0m3Z5T1swF1k3S19tOUJRAwU z4ZZcIChLZZ/+Le+WWSjtcG5i/9F2iqm6aa0Qvob2pfOg/EhFehxVCyqTiuP2cG8 d+v9QuHNBIqdY5Hjd8AueyasiAUXA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheejgddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrg hssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DB5633280066; Sun, 26 Apr 2020 16:06:04 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Jerin Jacob , dpdk-dev , Maxime Coquelin , Zhihong Wang , "Ye, Xiaolong" , David Marchand , Harman Kalra Date: Sun, 26 Apr 2020 22:06:03 +0200 Message-ID: <6277521.uz5P2jW1tq@thomas> In-Reply-To: References: <20200426173811.49788-1-jerinj@marvell.com> <3102527.CAdn2TfLgq@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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 devices 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 *dev) > > > FOREACH_DRIVER_ON_PCIBUS(dr) { > > > + if (dev->kdrv == RTE_KDRV_NONE) > > > + continue; > > > rc = 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 = pci_ioport_map(dev, bar, p); #endif break; David, please could you refresh our memory?