From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 38478282 for ; Tue, 14 Feb 2017 15:47:16 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2017 06:46:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,161,1484035200"; d="scan'208";a="44292648" Received: from dwdohert-mobl.ger.corp.intel.com (HELO [10.252.1.85]) ([10.252.1.85]) by orsmga002.jf.intel.com with ESMTP; 14 Feb 2017 06:46:57 -0800 To: Thomas Monjalon , dev@dpdk.org, Pablo DeLara Guarch References: <1522880.cuOTJ3FilR@xps13> <1704265.GvoO55czvH@xps13> From: "Doherty, Declan" Message-ID: <18f43aad-8ae8-3549-aabb-fa7618b1c36a@intel.com> Date: Tue, 14 Feb 2017 14:46:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1704265.GvoO55czvH@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] crypto drivers in the 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, 14 Feb 2017 14:47:17 -0000 On 14/02/2017 11:04 AM, Thomas Monjalon wrote: > 2017-02-14 10:44, Doherty, Declan: >> On 13/02/2017 1:25 PM, Thomas Monjalon wrote: >>> In the crypto API, the drivers are listed. >>> In my opinion, it is a wrong designed and these lists should be removed. >>> Do we need a deprecation notice to plan this removal in 17.05, while >>> working on bus abstraction? >>> >> ... >>> ... > > Yes > If you were planning to do this, you should have sent a deprecation notice > few weeks ago. > Please send it now and we'll see if we have enough supporters shortly. > Thomas, there are a couple of other changes we are looking at in the cryptodev which would require API changes as well as break ABI including adding support for a multi-device sessions, and changes to crypto operation layout and field changes for performance but these but will require RFCs or at least more discussion of the proposals. Given the time constrains for the V1 deadline for 17.05 I would prefer to work on the RFCs and get them out as soon as possible over the next few weeks and then make all the ABI breaking changes in R17.08 in a single release. Otherwise we will end up breaking ABI 2 release in a row which I would like to avoid if possible.