From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: 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 To: Stephen Hemminger Cc: dev@dpdk.org, stable@dpdk.org, Matan Azrad 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-dev] [PATCH 08/11] ethdev: fix port visibility before initialization 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, 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 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 > > Signed-off-by: Matan Azrad > > 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.