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 B6F307D5E for ; Thu, 24 Aug 2017 00:06:22 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 31AFB20D4A; Wed, 23 Aug 2017 18:06:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 23 Aug 2017 18:06:22 -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:x-sasl-enc; s=mesmtp; bh=/bpXZDv+la05WoL mHsRdudLSIYYBI6W4mO46178PqCI=; b=ItR2+qdwPe/+Wu+etP1nRCshtFaCRiR IVLQNOKpyBlNTM55upaNYMmXoddM81i5Pkbj+K10CyJEWUfz/z1gaxvNy1b0hnuI mW8MZ3HWxiQXJPp1FAhKqDV3caNkxYEYcZxmDlqgZbA8Y//8L/kyLzJQOjfyN8oi SXhsvCl52T7c= 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:x-sasl-enc; s= fm1; bh=/bpXZDv+la05WoLmHsRdudLSIYYBI6W4mO46178PqCI=; b=rOKytxxm TbQd6gumUdDi0mEb6BmvGi43dGnAv3eN4GzJHPyrpsrKbiQS4BCed0NxIzYPLP6I 5TWEVeiN2jtMqVaKUSeMB6ZW8Oh4T6h5EQorLpifpxZU0GLpFFjYhsyr3vzoDVRB snLg1bdOF9/p5qVC8dNSfwpRhLny1LNjKfrTI/d8WreIbdde+jOy3ZI5VYT6Iiek a9C+RcborpshrOl3Fc8oFGbdwy7OUmh6ox0X3OaHZeQqNwWwYdVyx0bwqXO6Y6AN 3mst4TctyRL0L+2r2Uo7UhmvPYWCb9nD3T0UtRm1PQVZqvilV8hiHHlw8fxQsgcx Qy3/MSx3QMmYaA== X-ME-Sender: X-Sasl-enc: TRBlVcFEsqI458oayG6gh4t72KU6iTbtrDrPLkAJtfls 1503525981 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D7CD87E6AD; Wed, 23 Aug 2017 18:06:21 -0400 (EDT) From: Thomas Monjalon To: Shahaf Shuler Cc: dev@dpdk.org, "Ananyev, Konstantin" Date: Thu, 24 Aug 2017 00:06:21 +0200 Message-ID: <5969739.W1oj9hpjs5@xps> In-Reply-To: References: <2601191342CEEE43887BDE71AB977258489B5073@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new offloads API 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: Wed, 23 Aug 2017 22:06:23 -0000 23/08/2017 15:13, Shahaf Shuler: > Wednesday, August 23, 2017 3:29 PM, Ananyev, Konstantin: > > From: Shahaf Shuler > > > In order to enable PMDs to support only one of the APIs, and > > > applications to avoid branching according to the underlying device a > > > copy functions to/from the old/new APIs were added. Looks a good intent. I would prefer the word "convert" instead of "copy". > > > int > > > rte_eth_rx_queue_setup(uint8_t port_id, uint16_t rx_queue_id, [...] > > > + } else if ((!(dev->data->dev_flags & RTE_ETH_DEV_RXQ_OFFLOAD)) && > > > + (dev->data->dev_conf.rxmode.ignore == 1)) { > > > + int ret; > > > + struct rte_eth_rxmode rxmode; > > > + > > > + rte_eth_copy_rxq_offloads(&rxmode, rx_conf); > > > + if (memcmp(&rxmode, &dev->data->dev_conf.rxmode, > > > + sizeof(rxmode))) { > > > + /* > > > + * device which work with rxmode offloads API requires > > > + * a re-configuration in order to apply the new offloads > > > + * configuration. > > > + */ > > > + dev->data->dev_conf.rxmode = rxmode; > > > + ret = rte_eth_dev_configure(port_id, > > > + dev->data->nb_rx_queues, > > > + dev->data->nb_tx_queues, > > > + &dev->data->dev_conf); > > > > Hmm, and why we would need to reconfigure our device in the middle of rx > > queue setup? > > The reason is the old Rx offloads API is configured on device configure. > This if section is for applications which already moved to the new offload > API however the underlying PMD still uses the old one. Isn't it risky to re-run configure here? We could also declare this case as an error. I think applications which have migrated to the new API, could use the convert functions themselves before calling configure to support not migrated PMDs. The cons of my solution are: - discourage apps to migrate before all PMDs have migrated - expose a temporary function to convert API I propose it anyway because there is always someone to like bad ideas ;)