From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 67B1F1B53 for ; Tue, 29 Aug 2017 14:55:27 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 05:55:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,444,1498546800"; d="scan'208";a="123647495" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga004.jf.intel.com with ESMTP; 29 Aug 2017 05:55:03 -0700 To: Thomas Monjalon , Shahaf Shuler , "Ananyev, Konstantin" Cc: dev@dpdk.org References: <5969739.W1oj9hpjs5@xps> <2468395.3cLPV6SE8H@xps> From: Ferruh Yigit Message-ID: <79b9a132-9cf3-21cf-19d0-56291917a9d7@intel.com> Date: Tue, 29 Aug 2017 13:55:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2468395.3cLPV6SE8H@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Tue, 29 Aug 2017 12:55:27 -0000 On 8/25/2017 2:26 PM, Thomas Monjalon wrote: > 24/08/2017 09:12, Shahaf Shuler: >> Thursday, August 24, 2017 1:06 AM, Thomas Monjalon: >>> 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 ;) >> >> Yes. I tried to make it as simple as possible for application to move to the new API. >> Defining it as error flow, will enforce the application to check the PMD offload mode and branch accordingly. The conversion functions are a good helpers, yet the code remains complex due to the different cases with the different PMDs. >> >> Considering the re-configuration is risky, and without other ideas I will need to fall back to the error flow case. >> Are we OK with that? > > I think we can take the risk of keeping this call to > rte_eth_dev_configure() in the middle of rte_eth_rx_queue_setup(). > In theory it should be acceptable. > If we merge it soon, it can be better tested with every drivers. I doubt about taking that risk. Some driver does HW configuration via configure() and combination of start/stop, setup_queue and configure can be complex. I am for generating error for this case. Generating error also can be good motivation for PMDs to adapt new method.