From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B8CFA0613 for ; Tue, 27 Aug 2019 10:17:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 22D4D1C032; Tue, 27 Aug 2019 10:17:48 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2A9B61C02A for ; Tue, 27 Aug 2019 10:17:45 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 01:17:45 -0700 X-IronPort-AV: E=Sophos;i="5.64,436,1559545200"; d="scan'208";a="185219151" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 01:17:43 -0700 Date: Tue, 27 Aug 2019 09:17:40 +0100 From: Bruce Richardson To: Ray Kinsella Cc: Aaron Conole , dev@dpdk.org, vladimir.medvedkin@intel.com, john.mcnamara@intel.com, marko.kovacevic@intel.com Message-ID: <20190827081740.GB1740@bricha3-MOBL.ger.corp.intel.com> References: <20190822160717.13584-1-mdr@ashroe.eu> <9043b351-86cc-ecc6-2af9-1c04368cabca@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9043b351-86cc-ecc6-2af9-1c04368cabca@ashroe.eu> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v2 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 Mon, Aug 26, 2019 at 05:45:55PM +0100, Ray Kinsella wrote: > > > On 23/08/2019 16:49, Aaron Conole wrote: > > Ray Kinsella writes: > > > >> This patchset adds ABI version testing to the app/test unit test framework, > >> addressing 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? > >> > >> Starting with rte_lpm, I did the following:- > >> > >> * I reproduced mostly unmodified unit tests for the v2.0 ABI, taken from DPDK > >> 2.2 and 17.02. > >> * I reproduced the rte_lpm interface header from v2.0, including the inline > >> functions and remapping symbols to their 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 deprecate APIs, the > >> 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. > >> > >> v2: > >> > >> * Added LPM IPv6 test cases for the v2.0 ABI. > >> * Fixed a number of checkpatch errors, stop short of substantially reworking > >> the test code from the v2.0 ABI. > >> * Removed duplicating test cases published in the original v1 patch. > > > > Thanks for this work. I think it's useful. > > > > I see an error under aarch64 builds because there are some x86_64 > > specific types being used in the testing. > > So the problem is that LPM didn't fully support ARM until DPDK v16.04. > The ABI versioning code in the LPM library is there to support the 2.0 ABI. > > The intention of this unit test is to test backward's compatibility with > an inline LPM function from DPDK v2.2.0, which was essentially x86 only > at that time. > > Unless we want to get into the business of backporting ARM support to > DPDK 2.2.0 (from where this test cases came from) - we should probably > restrict these ABI versioning test cases to CONFIG_RTE_ARCH_X86_64 only. > > The other option is forget about testing this the LPM ABI versioning > support, which then asks the question should be perhaps excise that code > altogether. > I think function versioning is great and should be widely used. Unfortunately, though, in our case since we break the ABI so consistently, this old code is pretty useless. Therefore, I think we should remove all old versionned code from e.g. pre-18.11, since no app is realistically going to work from that far back anyway. /Bruce