From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 2147F2C23 for ; Thu, 10 May 2018 23:49:13 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C1C21224BC; Thu, 10 May 2018 17:49:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 10 May 2018 17:49:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=RXYSz020bwlm9+aU/zhEFnrb6+ 8YEnv+jCua6rkuO6s=; b=RTDepVtNhgZBdwLtR/8hlnFxxaUT7g/Qd24to+HeZ+ 95n+GpoLInedwVz8MMDO+pPnuOfa7MOW60I1r8/MQJg5TiysPUcIA1i26NgGYGP3 dvNE5mq2ds5xpE3oTl8DFycT23c5xN7bmTqF39v8sCSyenFDj8OivZmLGus5lWIe A= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RXYSz0 20bwlm9+aU/zhEFnrb6+8YEnv+jCua6rkuO6s=; b=nanrE3AzTLyRiXRlKbHk96 ekuVv2Ov3LWMzHXyf9E0rElgrrZblNlHXrFrZcPQaU4fLvKz9dLD1CWbn7c5+ux0 zmMtxFfXbF8TidG+G8DvZ2aWkccLhrPgK6M374G6WBXa2kcoy+nzP7yCFm+u3VQK 9Ccoss6T+gzlCMM+Kn/O/C106vC2fSxVhSDYRrWWKnUCgi3mj7ZAPfJoVON1N/9v Y2+F5kJ8VdrJO9t4/hh38rG/vmjZKoxyd/ymoTG2Ti0bAOXYBEL8KQt9DciSNlsX 16llXIpcu9rX8W7117/AdqJfKfrQYvkjTMS4BlQcyDpfuR8aNWVM54l35BbRsXfw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 42093E4488; Thu, 10 May 2018 17:49:12 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org Date: Thu, 10 May 2018 23:49:11 +0200 Message-ID: <3664796.FEB3p8QtNK@xps> In-Reply-To: <20180510131803.0a691171@xeon-e3> References: <20180509094337.26112-1-thomas@monjalon.net> <20180509094337.26112-6-thomas@monjalon.net> <20180510131803.0a691171@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 05/11] ethdev: add probing finish function 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: , X-List-Received-Date: Thu, 10 May 2018 21:49:13 -0000 10/05/2018 22:18, Stephen Hemminger: > On Wed, 9 May 2018 11:43:31 +0200 > Thomas Monjalon wrote: > > > A new hook function is added and called inside the PMDs at the end > > of the device probing: > > - in primary process, after allocating, init and config > > - in secondary process, after attaching and local init > > > > This new function is almost empty for now. > > It will be used later to add some post-initialization processing. > > > > For the PMDs calling the helpers rte_eth_dev_create() or > > rte_eth_dev_pci_generic_probe(), the hook rte_eth_dev_probing_finish() > > is called from here, and not in the PMD itself. > > > > Note that the helper rte_eth_dev_create() could be used more, > > especially for vdevs, avoiding some code duplication in PMDs. > > > > Cc: stable@dpdk.org > > > > Signed-off-by: Thomas Monjalon > > --- > > drivers/net/af_packet/rte_eth_af_packet.c | 2 ++ > > drivers/net/ark/ark_ethdev.c | 2 ++ > > drivers/net/bonding/rte_eth_bond_pmd.c | 2 ++ > > drivers/net/cxgbe/cxgbe_ethdev.c | 1 + > > drivers/net/cxgbe/cxgbe_main.c | 5 +++++ > > drivers/net/cxgbe/cxgbevf_ethdev.c | 1 + > > drivers/net/cxgbe/cxgbevf_main.c | 5 +++++ > > drivers/net/dpaa/dpaa_ethdev.c | 5 ++++- > > drivers/net/dpaa2/dpaa2_ethdev.c | 4 +++- > > drivers/net/failsafe/failsafe.c | 2 ++ > > drivers/net/kni/rte_eth_kni.c | 2 ++ > > drivers/net/mlx4/mlx4.c | 1 + > > drivers/net/mlx5/mlx5.c | 2 ++ > > drivers/net/mvpp2/mrvl_ethdev.c | 1 + > > drivers/net/nfp/nfp_net.c | 2 ++ > > drivers/net/null/rte_eth_null.c | 2 ++ > > drivers/net/octeontx/octeontx_ethdev.c | 3 +++ > > drivers/net/pcap/rte_eth_pcap.c | 2 ++ > > drivers/net/ring/rte_eth_ring.c | 1 + > > drivers/net/softnic/rte_eth_softnic.c | 3 +++ > > drivers/net/szedata2/rte_eth_szedata2.c | 2 ++ > > drivers/net/tap/rte_eth_tap.c | 2 ++ > > drivers/net/vhost/rte_eth_vhost.c | 2 ++ > > drivers/net/virtio/virtio_user_ethdev.c | 3 +++ > > lib/librte_ethdev/rte_ethdev.c | 9 +++++++++ > > lib/librte_ethdev/rte_ethdev_driver.h | 10 ++++++++++ > > lib/librte_ethdev/rte_ethdev_pci.h | 2 ++ > > lib/librte_ethdev/rte_ethdev_version.map | 1 + > > test/test/virtual_pmd.c | 2 ++ > > 29 files changed, 79 insertions(+), 2 deletions(-) > > Rather than changing so many drivers would it be possible to put the finish in bus layer? > For virtual devices could be handle by vdev_probe_all_drivers. No, the bus layer does not know the ethdev ports created. A lot of drivers are not changed because they use a high level helper rte_eth_dev_pci_generic_probe or rte_eth_dev_create. For others, it is my comment in the commit log: Note that the helper rte_eth_dev_create() could be used more, especially for vdevs, avoiding some code duplication in PMDs.