From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id F234D1BB1F;
Fri, 11 May 2018 00:18:51 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id 5FE6C20A81;
Thu, 10 May 2018 18:18:51 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute1.internal (MEProxy); Thu, 10 May 2018 18:18:51 -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=oG61mZh5KchWoMNPPd4JBACkzd
yFTR9xflXYEqbAac4=; b=Rsp6DAdWHzGA6AcDpQOdpu5GYX6/N/B8WPf2hG+6/I
nPz+9ge6wvsG6eu4w9GdCFdhN2nfbkgY91PpM2A45YcDNLW8jV8Z4QqPwDax20Kl
x1/0NrNo9mjXHfbNJXqidHsCyTcEYxSUAKsVrhdDor4mpaFepcOIDSaTpIm6xMUl
Q=
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=oG61mZ
h5KchWoMNPPd4JBACkzdyFTR9xflXYEqbAac4=; b=YawKzy1fOpOn0T1fua38rE
4XRQ3v8TzTjhbNhlFKQqoq0P0bgP7wSks8wMEnobyG/Dmaft7EwTbFqm+WQMF/HD
ziawIFDxfABstkTUy3JpQt/u4BFtWIhGGIMpgvpluiAi7Yuqq2cwwo9c1gUONHhr
reBhRd4YJBlcB3YbPqTJfFlA8MKGzHwvNcADRge+qgXWpJVmdUEsfvWB0mi3sFjU
AYW9oz99A+pFsDecBqgaOM1jzSHoX4ldv+SQ3NmcYRyJ/7RpK+hQBQ4Ytu0G6YWl
G5+P9we7Pvs/Dp3TDy0tlh8bjpIUvK2iuenfUBgSx/ON40E6hyHDfJ6Zo92TYhMQ
==
X-ME-Sender: <xms:S8X0WvK7gARI0WQU4Msgwf0htvgcuvmF3EugdOOlD1AWziUDuuURfQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id 873C4E444A;
Thu, 10 May 2018 18:18:50 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, stable@dpdk.org, Matan Azrad <matan@mellanox.com>
Date: Fri, 11 May 2018 00:18:49 +0200
Message-ID: <1765432.VqHX3uhuI3@xps>
In-Reply-To: <20180510134056.455d97dc@xeon-e3>
References: <20180509094337.26112-1-thomas@monjalon.net>
<20180509094337.26112-9-thomas@monjalon.net>
<20180510134056.455d97dc@xeon-e3>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 08/11] ethdev: fix port
visibility before initialization
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 22:18:52 -0000
10/05/2018 22:40, Stephen Hemminger:
> On Wed, 9 May 2018 11:43:34 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > The port was set to the state ATTACHED during allocation.
> > The consequence was to iterate over ports which are not initialized.
> >
> > The state ATTACHED is now set as the last step of probing.
> >
> > The uniqueness of port name is now checked before the availability
> > of a port id for allocation (order reversed).
> >
> > As the state is not set on allocation anymore, it is also not checked
> > in the function telling whether a port is allocated or not.
> > The name of the port is set on allocation, so it is enough as a check.
> >
> > Fixes: 5588909af21b ("ethdev: add device iterator")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > Signed-off-by: Matan Azrad <matan@mellanox.com>
>
> Could these states be described somewhere in the documentation.
It is in this patchset:
ethdev: add doxygen comments for each state
> Maybe some doc/guides? Maybe even exposed in API under rte_eth_dev_info.
It is an internal state. It should not be used by the application.
> Ideally, the device states could be aligned to the SNMP MIB for
> interfaces (RFC2863) which defines complex state model appropriate for devices
> and tunnels.
Something to be discussed, MIB compliance would be a totally new feature
I guess. I think it is a huge work with not a lot of interest.