From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 004AD23C for ; Thu, 18 Jan 2018 18:18:25 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 09:18:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,378,1511856000"; d="scan'208";a="20815970" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.48]) ([10.237.220.48]) by FMSMGA003.fm.intel.com with ESMTP; 18 Jan 2018 09:18:23 -0800 To: Matan Azrad , Adrien Mazarguil , Gaetan Rivet Cc: Thomas Monjalon , dev@dpdk.org References: <1516220357-13013-1-git-send-email-matan@mellanox.com> <1516274834-19755-1-git-send-email-matan@mellanox.com> <1516274834-19755-2-git-send-email-matan@mellanox.com> From: Ferruh Yigit Message-ID: <2ffac5e9-6be5-0c82-18c4-8b72710630ae@intel.com> Date: Thu, 18 Jan 2018 17:18:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1516274834-19755-2-git-send-email-matan@mellanox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v6 1/6] ethdev: add devop to check removal status 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, 18 Jan 2018 17:18:26 -0000 On 1/18/2018 11:27 AM, Matan Azrad wrote: > There is time between the physical removal of the device until PMDs get > a RMV interrupt. At this time DPDK PMDs and applications still don't > know about the removal. > > Current removal detection is achieved only by registration to device RMV > event and the notification comes asynchronously. So, there is no option > to detect a device removal synchronously. > Applications and other DPDK entities may want to check a device removal > synchronously and to take an immediate decision accordingly. So we will have two methods to detect device removal, one is asynchronous as you mentioned. Device removal will cause an interrupt which trigger to run user callback. New method is synchronous, but still triggered from application. I mean application should do a rte_eth_dev_is_removed() to learn about status, what is the use case here, polling continuously? Won't this also cause some latency unless you dedicate a core just polling device status? > > Add new dev op called is_removed to allow DPDK entities to check an > Ethernet device removal status immediately. > > Signed-off-by: Matan Azrad > Acked-by: Thomas Monjalon > --- > lib/librte_ether/rte_ethdev.c | 28 +++++++++++++++++++++++++--- > lib/librte_ether/rte_ethdev.h | 20 ++++++++++++++++++++ > lib/librte_ether/rte_ethdev_version.map | 1 + > 3 files changed, 46 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index b349599..c93cec1 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -114,7 +114,8 @@ enum { > rte_eth_find_next(uint16_t port_id) > { > while (port_id < RTE_MAX_ETHPORTS && > - rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED) > + rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED && > + rte_eth_devices[port_id].state != RTE_ETH_DEV_REMOVED) If device is removed, why we are not allowed to re-use port_id assigned to it? Overall I am not clear with RTE_ETH_DEV_REMOVED state, why we are not directly setting RTE_ETH_DEV_UNUSED? And state RTE_ETH_DEV_REMOVED set in ethdev layer, and ethdev layer won't let reusing it, so what changes the state of dev? Will it stay as it is during lifetime of the application? > port_id++; > > if (port_id >= RTE_MAX_ETHPORTS) > @@ -262,8 +263,7 @@ struct rte_eth_dev * > rte_eth_dev_is_valid_port(uint16_t port_id) > { > if (port_id >= RTE_MAX_ETHPORTS || > - (rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED && > - rte_eth_devices[port_id].state != RTE_ETH_DEV_DEFERRED)) > + (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED)) > return 0; > else > return 1; > @@ -1094,6 +1094,28 @@ struct rte_eth_dev * > } > > int > +rte_eth_dev_is_removed(uint16_t port_id) > +{ > + struct rte_eth_dev *dev; > + int ret; > + > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0); > + > + dev = &rte_eth_devices[port_id]; > + > + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->is_removed, 0); > + > + if (dev->state == RTE_ETH_DEV_REMOVED) > + return 1; Isn't this conflict with below API documentation: " * @return * - 0 when the Ethernet device is removed, otherwise 1. " > + > + ret = dev->dev_ops->is_removed(dev); > + if (ret != 0) > + dev->state = RTE_ETH_DEV_REMOVED; It isn't clear what "dev_ops->is_removed(dev)" should return, and this causing incompatible usages in PMDs by time. Please add some documentation about expected return values for dev_ops. And this not real remove, PMD signals us and we stop using that device, but device can be there, right? If there is a real removal, can be possible to use eal hotplug? <...>