From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 5B21B5F34; Wed, 9 May 2018 21:13:07 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 05294227DB; Wed, 9 May 2018 15:13:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 09 May 2018 15:13:07 -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=21rBV8mUOgX0K9+cELnC/Y56xr BudIvU74hhgNBtMCA=; b=g66JlA0u0lzKOyLHXjnRX4L21kknd69LU/DWFbq54R KU/0xB1lbqbd+cvd4aiHe3RErMBKyuYpG8G1NE5X7McCU6pRUHLZrLQ8QynvQoKt +Wlaj1eRWN28cLVoEqP+qfTYAQ6OwDVa33X3kRO5UFfdk8+K+rCXs2DCQr0gVqOU s= 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=21rBV8 mUOgX0K9+cELnC/Y56xrBudIvU74hhgNBtMCA=; b=frMRv/70Oowy36ltbXl0b2 7fseWf7DeB81+LOXrmF1Y28RmfG1dCtmWZwAGNSE7HYZ6mghsH4A4l8ZtkkTU9ei V0ZnrXUBrhgAL3jy5r0+QMSc2dnHWr90JBM3Nadf90U4IZ6YNaMDTfghKs/fXp2x hBqwYNVjYw5DxhGWqDE3hT6HX5//HCgyGZJCrwh34M2zi0VwDH/gHq/NE/IcbSIg npb44moL0A32Y7wzbHAu5lQCJHtpJrI/pJ3kIKBuTMKLgQhZOSmTPj5ecPBis5nu GOdhIpd3+3CYLkGEar9n887G6INvQbW8mJh5JlNNB5hvFtoTko0dVpQZBJafvhCg == 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 5035FE4EEF; Wed, 9 May 2018 15:13:06 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, stable@dpdk.org Date: Wed, 09 May 2018 21:13:05 +0200 Message-ID: <1698026.CzQui4UTeb@xps> In-Reply-To: <050d4b36-a6d5-5044-3462-e751642ea1ff@intel.com> References: <20180509094337.26112-1-thomas@monjalon.net> <20180509094337.26112-10-thomas@monjalon.net> <050d4b36-a6d5-5044-3462-e751642ea1ff@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 09/11] ethdev: fix port probing notification 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: Wed, 09 May 2018 19:13:07 -0000 09/05/2018 20:07, Ferruh Yigit: > On 5/9/2018 10:43 AM, Thomas Monjalon wrote: > > @@ -3386,6 +3383,8 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev) > > if (dev == NULL) > > return; > > > > + _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL); > > + > > Technically we can have as many ethdev created as we want in probe() right? Yes probing can create several ports. > Doesn't have to be a one to one mapping there, having user event in > rte_eth_dev_allocate() guaranties each ethdev created sends the event. Allocation is too early to notify a new port. We need to wait it is initialized before using it. > But when you moved this into probe() now one event sent for event, same comment > for previous one, I don't think it is good idea to tie ethdev allocation with > probe() The PMD sends one event per port by calling the appropriate ethdev function. Event and allocation are not tied. I don't see the issue. Note the definition of this event has always been about probing, not allocation: RTE_ETH_EVENT_NEW, /**< port is probed */