Message ID | 20190528115158.73245-1-ray.kinsella@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7BBD91B956; Tue, 28 May 2019 15:12:58 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 170442C55 for <dev@dpdk.org>; Tue, 28 May 2019 13:53:00 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2019 04:53:00 -0700 X-ExtLoop1: 1 Received: from silpixa00395806.ir.intel.com (HELO silpixa00395806.ger.corp.intel.com) ([10.237.222.41]) by fmsmga001.fm.intel.com with ESMTP; 28 May 2019 04:52:59 -0700 From: Ray Kinsella <ray.kinsella@intel.com> To: bruce.richardson@intel.com, vladimir.medvedkin@intel.com Cc: dev@dpdk.org, Ray Kinsella <ray.kinsella@intel.com> Date: Tue, 28 May 2019 12:51:56 +0100 Message-Id: <20190528115158.73245-1-ray.kinsella@intel.com> X-Mailer: git-send-email 2.17.1 X-Mailman-Approved-At: Tue, 28 May 2019 15:12:47 +0200 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
Add ABI Version Testing to app/test
|
|
Message
Kinsella, Ray
May 28, 2019, 11:51 a.m. UTC
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. Ray Kinsella (2): app/test: Add ABI Version Testing functionality app/test: LPMv4 ABI Version Testing app/test/Makefile | 12 +- app/test/commands.c | 131 ++- app/test/meson.build | 5 + app/test/test.c | 2 + app/test/test.h | 52 +- app/test/test_lpm.c | 1 + app/test/test_lpm_perf.c | 293 +------ app/test/test_lpm_routes.c | 287 +++++++ app/test/test_lpm_routes.h | 25 + app/test/v16.04/dcompat.h | 23 + app/test/v16.04/rte_lpm.h | 463 +++++++++++ app/test/v16.04/rte_lpm_neon.h | 119 +++ app/test/v16.04/rte_lpm_sse.h | 120 +++ app/test/v16.04/test_lpm.c | 1405 ++++++++++++++++++++++++++++++++ app/test/v16.04/test_v1604.c | 14 + app/test/v2.0/dcompat.h | 23 + app/test/v2.0/rte_lpm.h | 443 ++++++++++ app/test/v2.0/test_lpm.c | 1306 +++++++++++++++++++++++++++++ app/test/v2.0/test_v20.c | 14 + 19 files changed, 4420 insertions(+), 318 deletions(-) create mode 100644 app/test/test_lpm_routes.c create mode 100644 app/test/test_lpm_routes.h create mode 100644 app/test/v16.04/dcompat.h create mode 100644 app/test/v16.04/rte_lpm.h create mode 100644 app/test/v16.04/rte_lpm_neon.h create mode 100644 app/test/v16.04/rte_lpm_sse.h create mode 100644 app/test/v16.04/test_lpm.c create mode 100644 app/test/v16.04/test_v1604.c create mode 100644 app/test/v2.0/dcompat.h create mode 100644 app/test/v2.0/rte_lpm.h create mode 100644 app/test/v2.0/test_lpm.c create mode 100644 app/test/v2.0/test_v20.c
Comments
Someone kindly approved it, and saved me sending it again from the right email a/c, thank you. On 28/05/2019 13:08, Bruce Richardson wrote: > 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. I did think about that also - the test binary, similar to testpmd is very busy. I sought to mitigate that with set_abi_version command, mitigating unit test name collisions etc. I would have a huge concern about putting it into a separate binary, as these tcs would quickly become forgotten about. > > A separate question is whether this is really necessary to ensure ABI > compatibility? I would argue that we currently have no idea if ABI versioned functions actually work? Why offer backward compatibility, if we don't test it? > Do other projects do this? The C++ stdlib is many ways similar to DPDK, ABI compatibility is a well understood problem over there. See the following presentation Slide 20. https://accu.org/content/conf2015/JonathanWakely-What%20Is%20An%20ABI%20And%20Why%20Is%20It%20So%20Complicated.pdf They have a small corpus of TC's for this https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/testsuite/[backward,abi] > Is the info from the abi > compatiblity checker script already in DPDK, or from other > already-available tools not sufficient? Well this just tells you that you ABI has changed. We don't have anything at the moment that tells us that the ABI compatible functions actually work ... ? > > /Bruce >