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 1C0342BF3 for ; Wed, 30 Aug 2017 15:25:36 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AD6C520C2E; Wed, 30 Aug 2017 09:25:35 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 30 Aug 2017 09:25:35 -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=PV3pJM0kbOHJ2zu lVY71woFHCYJ8CCP6m8C1g9/eBxo=; b=YekZOrvbmHMgx105e9gcOaCVlJbXhST +HbNJChTGRLnCA6tk57K7IRZJ/OFHju3MkIttqT84+B6iF4urnNY8ZYYEun5Le8s gvtFVTX+xdXR2F1TvJtY43QaBLCKVJ8z8afLOWKYRpv9MlUPzK1/GRpqu3J41JEi zuooJHgcGg80= 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=PV3pJM0kbOHJ2zulVY71woFHCYJ8CCP6m8C1g9/eBxo=; b=O2SHj/cG ShZVE8hoQ/oEqsTHI8twkSYv3q/Ft/w/FNxvdyjEsnwtjJzan+oSpEoUVsKFMJCz uPioYeOnfC66Tdl/inq+TmSOtGlW2H/NuXtlqVcjMNbJnSjJtMGhobUfTJk5EK6H +qs+HZLXShlAJ3HSvCbcJRQP3IHRflZEzpq1EujKkAulssBX+o+xI3jRPC6kg5Qb SdaFUyMm3U+jYeoAUEE0mhyHUvGPaHqP0pMmuztYO5ZALbmoOcjTyRlpyNoRK/6S FzkIxRqiFWSqUqUc41vrewbeKn1T6HJJa/1asA4h9/DFYPiYuTnZD6Df+TeaC7eL FL4wt1rxYfaB5Q== X-ME-Sender: X-Sasl-enc: OsiaOFjceSbmO5bHcyfRjwU2VCeVCmGkwdixK410E0lz 1504099535 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5AFFB246D5; Wed, 30 Aug 2017 09:25:35 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: "Ananyev, Konstantin" , Shahaf Shuler , dev@dpdk.org Date: Wed, 30 Aug 2017 15:25:34 +0200 Message-ID: <1557864.FHzAeJcJ5m@xps> In-Reply-To: <59831a36-6565-9c4f-2d8e-8bdb096246e3@intel.com> References: <2601191342CEEE43887BDE71AB9772584F23E217@IRSMSX103.ger.corp.intel.com> <59831a36-6565-9c4f-2d8e-8bdb096246e3@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, 30 Aug 2017 13:25:36 -0000 30/08/2017 14:42, Ferruh Yigit: > On 8/30/2017 11:16 AM, Ananyev, Konstantin wrote: > > Hi Ferruh, > > From: Yigit, Ferruh > >> 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? I think it is a reasonnable migration path. We will need you Ferruh to make sure all drivers will be converted soon, hopefully in 18.02.