From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 80734A045E for ; Tue, 28 May 2019 14:08:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7053C1B94C; Tue, 28 May 2019 14:08:14 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id AB263137D for ; Tue, 28 May 2019 14:08:08 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2019 05:08:07 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.64]) by fmsmga006.fm.intel.com with SMTP; 28 May 2019 05:08:05 -0700 Received: by (sSMTP sendmail emulation); Tue, 28 May 2019 13:08:04 +0100 Date: Tue, 28 May 2019 13:08:04 +0100 From: Bruce Richardson To: Ray Kinsella Cc: vladimir.medvedkin@intel.com, dev@dpdk.org Message-ID: <20190528120804.GA1095@bricha3-MOBL.ger.corp.intel.com> References: <20190528115158.73245-1-ray.kinsella@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190528115158.73245-1-ray.kinsella@intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 0/2] Add ABI Version Testing to app/test 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, May 28, 2019 at 12:51:56PM +0100, Ray Kinsella wrote: > This patchset adds ABI Version Testing functionality to the app/test unit > test framework. > > The patchset is intended to address two issues previously raised during ML > conversations on ABI Stability; > 1. How do we unit test still supported previous ABI Versions. > 2. How to we unit test inline functions from still supported previous ABI > Versions. > > The more obvious way to achieve both of the above is to simply archive > pre-built binaries compiled against previous versions of DPDK for use unit > testing previous ABI Versions, and while this should still be done as an > additional check, this approach does not scale well, must every DPDK > developer have a local copy of these binaries to test with, before > upstreaming changes? > > Instead starting with rte_lpm, I did the following:- > > * I reproduced mostly unmodified unit tests from previous ABI Versions, > in this case v2.0 and v16.04 > * I reproduced the rte_lpm interface header from these previous ABI > Versions,including the inline functions and remapping symbols to > appropriate versions. > * I added support for multiple abi versions to the app/test unit test > framework to allow users to switch between abi versions (set_abi_version), > without further polluting the already long list of unit tests available in > app/test. > > The intention here is that, in future as developers need to depreciate > APIs, their associated unit tests may move into the ABI Version testing > mechanism of the app/test instead of being replaced by the latest set of > unit tests as would be the case today. > > ToDo: > * Refactor the v2.0 and v16.04 unit tests to separate functional and > performance test cases. > * Add support for trigger ABI Version unit tests from the app/test command > line. > While I admire the goal, given the amount of code that seems to be involved here, I'm not sure if the "test" binary is the place to put this. I think it might be better as a separate ABI compatiblity test app. A separate question is whether this is really necessary to ensure ABI compatibility? Do other projects do this? Is the info from the abi compatiblity checker script already in DPDK, or from other already-available tools not sufficient? /Bruce