From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id 90EEE9986 for ; Wed, 16 Aug 2017 14:41:41 +0200 (CEST) Received: by mail-wr0-f171.google.com with SMTP id 49so6064312wrw.2 for ; Wed, 16 Aug 2017 05:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=91y1OPm7DbsXZUScSOO71ErNUMLnS+zjN0yNipCD80c=; b=IqowFuU8DdHFo1d5dCb2hidipcICUPB5PVFPbbHpBDj+3DoqPA54BQhj7+kxJn9XTG l7qGQy4PF+hEkKcYegX7aAyMirOYx+anxieGPb6r2KgEdRSPePaa/EyHeUGj1NopuF0n aekG8YsctiVc9VKWviQPDoj7+a+heb0Wq6QkVxG8EIPH4zIgpy+g1k1k7Uy9PjkE5fSP e5vZEfCve1J/ondxBFeMFBKl0Oh3V13mXsvH6xfaxTTOqEVfKkWdbMjlWWTI66+IRox+ 4iWlXiFO+bxGRqAMv8jqRGZdm9cPELZzy6H+dkjtfsOnFr9heOd9aEUR/gJ5lvn20Lif vCeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=91y1OPm7DbsXZUScSOO71ErNUMLnS+zjN0yNipCD80c=; b=Rn0PKiygKoDhYIwuiB6CGtA3tymDR6X5/rn/MLdKEGrqWyGuYGwnYoGMpy6BH3leby 5AvLnW+rm7davmYYi7TOqm7rDf6ZZaTxeqZd8sD+eXktWFy+3f9g6oVYKQ7FdAYWxxcc jXaiuvc8gmnBx4oE7mzzdnCahm/5C73NEHwg9EUHuk+LlhM6oFAejc+dhZ7m5BM+mjKN DnnEhdKLGTkLrzNZAAGSlgRTgPfjCTXETzatF6neZt1/owLaTtDqT/UorLBls7Uh2Dfe 8w6gxABK9LhfjV9IYCm7jyRldRewjGJblO0paonjQXa1Lw8R+lwpmQ80JfmLGeOZmLYO DekA== X-Gm-Message-State: AHYfb5htpBKFU697/yjGqjb1hLCMeE+Wt8XmkEbXoLD9WaX1IRCWnnJn QG8RFMVYQViuwdM6 X-Received: by 10.28.128.212 with SMTP id b203mr1358162wmd.170.1502887300932; Wed, 16 Aug 2017 05:41:40 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id q21sm998987wra.86.2017.08.16.05.41.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 05:41:40 -0700 (PDT) Date: Wed, 16 Aug 2017 14:41:30 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Shahaf Shuler Cc: thomas@monjalon.net, dev@dpdk.org, stable@dpdk.org Message-ID: <20170816124130.GL8124@bidouze.vm.6wind.com> References: <20170816114308.165850-1-shahafs@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170816114308.165850-1-shahafs@mellanox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-stable] [PATCH] ethdev: fix device state on close X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:41:41 -0000 Hello Shahaf, On Wed, Aug 16, 2017 at 02:43:08PM +0300, Shahaf Shuler wrote: > Currently device state moves between ATTACHED when device was > successfully probed to UNUSED when device is detached or released. > > The device state following rte_eth_dev_close() operation is inconsist, > The device is still in ATTACHED state, however it cannot be used > in any way till it will be probed again. > > Fixing it by changing the state to UNUSED. > You are right that simply closing the device leaves it in a unusable state. However it seems to be by design. Most drivers call `rte_eth_dev_release_port` when being removed, which sets the state to RTE_ETH_DEV_UNUSED. If I'm not mistaken, the API of rte_eth_dev_close is that the only available action should then be to detach the driver. At least PCI and vdev buses expects a `remove` callback from their driver, which can be called by the user (previously using specific API like `rte_eal_vdev_uninit` for example, now using `rte_eal_hotplug_remove` or `rte_eth_dev_detach` from the ether layer). So, it seems that this burden lies with the driver which should call the proper API when removing their device. Maybe Thomas will have a better insight about the scope of the `rte_eth_dev_close` function. But IMO the API is respected. After all, until the proper `dev_detach` function is called, the device is still attached, even if closed. If you disagree, there might possibly be an argument to make about either adding finer-grained device states or streamlining the API. This is however a discussion about API design and not about its implementation anymore. > Fixes: d52268a8b24b ("ethdev: expose device states") > Cc: gaetan.rivet@6wind.com > Cc: stable@dpdk.org > > Signed-off-by: Shahaf Shuler > --- > lib/librte_ether/rte_ethdev.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index 0597641ee..98d9e929c 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -992,6 +992,8 @@ rte_eth_dev_close(uint8_t port_id) > dev->data->nb_tx_queues = 0; > rte_free(dev->data->tx_queues); > dev->data->tx_queues = NULL; > + > + dev->state = RTE_ETH_DEV_UNUSED; > } > > int > -- > 2.12.0 > -- Gaëtan Rivet 6WIND