From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 079DA2C02 for ; Wed, 30 Aug 2017 14:42:33 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 05:42:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,448,1498546800"; d="scan'208";a="143666252" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga005.jf.intel.com with ESMTP; 30 Aug 2017 05:42:31 -0700 To: "Ananyev, Konstantin" , Shahaf Shuler , Thomas Monjalon Cc: "dev@dpdk.org" References: <5969739.W1oj9hpjs5@xps> <2468395.3cLPV6SE8H@xps> <79b9a132-9cf3-21cf-19d0-56291917a9d7@intel.com> <8503fb63-7ea3-4c81-6781-fa19569b7ad0@intel.com> <2601191342CEEE43887BDE71AB9772584F23E217@IRSMSX103.ger.corp.intel.com> From: Ferruh Yigit Message-ID: <59831a36-6565-9c4f-2d8e-8bdb096246e3@intel.com> Date: Wed, 30 Aug 2017 13:42:30 +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: <2601191342CEEE43887BDE71AB9772584F23E217@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 30 Aug 2017 12:42:34 -0000 On 8/30/2017 11:16 AM, Ananyev, Konstantin wrote: > Hi Ferruh, > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Wednesday, August 30, 2017 8:51 AM >> To: Shahaf Shuler ; Thomas Monjalon ; Ananyev, Konstantin >> >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [RFC PATCH 4/4] ethdev: add helpers to move to the new offloads API >> >> On 8/30/2017 7:30 AM, Shahaf Shuler wrote: >>> Tuesday, August 29, 2017 3:55 PM, Ferruh Yigit: >>>>>> 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. >>> >>> Adding Ananyev suggestion from other thread: >>> For tx_prepare() work, we used the following approach: >>> 1. submitted patch with changes in rte_ethdev and PMDs we are familiar with (Intel ones). >>> For other PMDs - patch contained just minimal changes to make it build cleanly. >>> 2. Asked other PMD maintainers to review rte_ethdev changes and provide a proper patch >>> for the PMD they own. >> >> tx_prepare() is a little different, since it was not clear if all PMDs >> needs updating that is why asked to PMD owners, and the ones requires >> updating already has been updated with ethdev patch. Here we know all >> PMDs need updating, and they need proper time in advance. >> >>> >>> So I am OK with both suggestions. Meaning: >>> 1. Define the case were application use the new offloads API with PMD which supports the old one as an error. >>> 2. apply patches to ethdev with the above behavior. >>> >>> Just to emphasize, it means that PMDs which won't move to the new API by the end of 17.11 will not be able to run with any of the >> examples and application on DPDK tree (and also with other applications which moved to the new API), as I plan to submit patches which >> convert them all to the new API. >> >> I think it is good idea to update samples/apps to new method, but this >> can be short notice for PMD owners. >> >> Can we wait one more release to update samples/apps, to give time for >> PMDs to be updated, since old applications will work with new PMDs >> (thanks to your helpers), I believe this won't be a problem. > > I am not sure what is your suggestion here? > Support both flavors of PMD API for 17.11? Support both with an exception, when application uses new method but PMD uses old one, throw an error (because of above discussed technical issue). This lets existing applications run without problem, and pushes PMDs to adapt new method. Your suggestion to have only new method and convert all PMDs to new method is good, but I am not sure if this is realistic for this release, since different PMDs have different pace for updates. ethdev updates can be done in this release, with the PMDs that already changed to new method. The sample/app modifications Shahaf mentioned can be done in the beginning of the next release, and this gives time to remaining PMDs until end of next release. What do you think? > Konstantin > >> >>> >>> Any objection to this approach? >>> >>> >