From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v2 0/3] clarify eth_dev state management
Date: Wed, 05 Apr 2017 22:46:59 +0200
Message-ID: <6571221.TDpU4kGvc7@xps13>
References: <cover.1488550937.git.gaetan.rivet@6wind.com>
 <cover.1490961533.git.gaetan.rivet@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, Jingjing Wu <jingjing.wu@intel.com>
To: Gaetan Rivet <gaetan.rivet@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com
 [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id 4D0A32C5
 for <dev@dpdk.org>; Wed,  5 Apr 2017 22:47:01 +0200 (CEST)
Received: by mail-wr0-f177.google.com with SMTP id t20so32530365wra.1
 for <dev@dpdk.org>; Wed, 05 Apr 2017 13:47:01 -0700 (PDT)
In-Reply-To: <cover.1490961533.git.gaetan.rivet@6wind.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2017-03-31 14:04, Gaetan Rivet:
> 1. The hotplug API currently available in DPDK introduces the notion of
>    device states (DEV_DETACHED, DEV_ATTACHED). These states are implicit
>    and internal to the ethdev layer.
> 
> 2. Device enumeration and access is done directly, without regard to the
>    underlying state of a device. Applications are currently expected to cycle
>    through the static rte_eth_devices array. Those using the hotplug API
>    (rte_eth_dev_attach(), rte_eth_dev_detach()), are thus expected to deal
>    themselves with possible discrepancies internal to the ethdev layer,
>    i.e. avoid detached devices if necessary, without the state of the devices
>    having been explicitly defined or exposed.
> 
> 3. The hotplug API itself is not complete and cannot be used without
>    introducing some bugs. Detaching a device will introduce inconsistencies in
>    the device count, as explained in the related API.
>    No function is exposed in the ethdev layer to permit applications to deal
>    with it.
> 
> This series addresses these issues so that:
> 
> 1. Applications are not expected to manage the states of their devices, those
>    should be kept internal to the ethdev layer.
> 
> 2. The hotplug API is cleaner, with specific operations from the ethdev layer
>    to be used if necessary.
> 
> 3. Applications that are not interested in hotplug functionality are not concerned
>    and do not require any change.

Applied, thanks