From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 31C0B1B8D9 for ; Tue, 10 Apr 2018 15:59:06 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B49F720FAC; Tue, 10 Apr 2018 09:59:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 10 Apr 2018 09:59:05 -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=o/IMjpyD3BliN9YyQrBRQgJ6Ud X3mWQ8ZOAnbxBmIko=; b=aKC4YkdsvwY4yLLBtv1UmgjsnpA9P7LGxGjW8CVCkg x35zttLBiZ4hxf+nv4GL8eumUziiaLJeZkrKtUmLRfRaNC4h+29t5AuJa6Of+DBu 9U+N71Fo1nJxseJbhsoqrN4jketQWpQZ/FFSnV7mbnweT7sd/590HtapRNsvRJGx M= 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=o/IMjp yD3BliN9YyQrBRQgJ6UdX3mWQ8ZOAnbxBmIko=; b=SZK2BSarAZqOdQ/61Ou4ry vrURxLvP7MRcc+edF9aC8sgwP2ck5d9NZiuvStWP5gMssTTJN1HHr/MXqk4eF99G LGgp489Q58m1BA8ytxjorO+jdMgJ2tMmcfUDhUGj5exr2L5N5/W9gKzGQZUWJzUC xZZk0ie6UPbMEL3gRBvZKtqIfmZ2UOX1sB6GubvogAsa8aH+V5fkQJhbyTKG74Cm epXsXOrAD+FoUU4biLcKmGN6pEloGbig1izxhvjVz5gzIiE8map9hI3k3LXQK7IN Z6gl5AxsitEiqSNiyJZ4RUrj7Bn7hDa+2ZehWL1Gj9NiAaQC9OvixNBG6UvrK/2w == 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 BAF22E43C8; Tue, 10 Apr 2018 09:59:04 -0400 (EDT) From: Thomas Monjalon To: Qi Zhang Cc: dev@dpdk.org, konstantin.ananyev@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com, wenzhuo.lu@intel.com Date: Tue, 10 Apr 2018 15:59:03 +0200 Message-ID: <9581683.2joz8NotYG@xps> In-Reply-To: <20180408024221.228450-2-qi.z.zhang@intel.com> References: <20180212045314.171616-1-qi.z.zhang@intel.com> <20180408024221.228450-1-qi.z.zhang@intel.com> <20180408024221.228450-2-qi.z.zhang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 1/3] ether: support runtime queue setup 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: Tue, 10 Apr 2018 13:59:06 -0000 Hi, Please replace ether and etherdev by ethdev (in title and text). 08/04/2018 04:42, Qi Zhang: > The patch let etherdev driver expose the capability flag through > rte_eth_dev_info_get when it support runtime queue configuraiton, typo: configuration > then base on the flag rte_eth_[rx|tx]_queue_setup could decide > continue to setup the queue or just return fail when device already > started. Generally speaking, it is easier to read when broke in several sentences, and starting with the problem statement. Example: " It is not possible to setup a queue when the port is started because of a check in ethdev layer. New capability flags are added in order to relax this check for devices which support queue setup in runtime. The functions rte_eth_[rx|tx]_queue_setup will raise an error only if the port is started and runtime setup of queue is not supported. " > > Signed-off-by: Qi Zhang > Acked-by: Konstantin Ananyev > --- > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -981,6 +981,11 @@ struct rte_eth_conf { > */ > #define DEV_TX_OFFLOAD_SECURITY 0x00020000 > > +#define DEV_RUNTIME_RX_QUEUE_SETUP 0x00000001 > +/**< Deferred setup rx queue */ > +#define DEV_RUNTIME_TX_QUEUE_SETUP 0x00000002 > +/**< Deferred setup tx queue */ Please use RTE_ETH_ prefix. > /* > * If new Tx offload capabilities are defined, they also must be > * mentioned in rte_tx_offload_names in rte_ethdev.c file. > @@ -1029,6 +1034,8 @@ struct rte_eth_dev_info { > /** Configured number of rx/tx queues */ > uint16_t nb_rx_queues; /**< Number of RX queues. */ > uint16_t nb_tx_queues; /**< Number of TX queues. */ > + uint64_t runtime_queue_setup_capa; > + /**< queues can be setup after dev_start (DEV_DEFERRED_). */ Why using uint64_t for that? Maybe these flags can find another place, less specific. What about a field for all setup capabilities? setup_capa?