From: Bruce Richardson <bruce.richardson@intel.com>
To: Ray Kinsella <mdr@ashroe.eu>
Cc: Aaron Conole <aconole@redhat.com>,
dev@dpdk.org, vladimir.medvedkin@intel.com,
john.mcnamara@intel.com, marko.kovacevic@intel.com
Subject: Re: [dpdk-dev] [PATCH v2 0/2] add abi version testing to app/test
Date: Tue, 27 Aug 2019 09:17:40 +0100 [thread overview]
Message-ID: <20190827081740.GB1740@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <9043b351-86cc-ecc6-2af9-1c04368cabca@ashroe.eu>
On Mon, Aug 26, 2019 at 05:45:55PM +0100, Ray Kinsella wrote:
>
>
> On 23/08/2019 16:49, Aaron Conole wrote:
> > Ray Kinsella <mdr@ashroe.eu> 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
next prev parent reply other threads:[~2019-08-27 8:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 16:07 Ray Kinsella
2019-08-22 16:07 ` [dpdk-dev] [PATCH v2 1/2] app/test: add abi version testing functionality Ray Kinsella
2019-08-22 16:07 ` [dpdk-dev] [PATCH v2 2/2] app/test: lpm abi version testing Ray Kinsella
2019-08-23 15:49 ` [dpdk-dev] [PATCH v2 0/2] add abi version testing to app/test Aaron Conole
2019-08-26 16:45 ` Ray Kinsella
2019-08-27 8:17 ` Bruce Richardson [this message]
2019-08-27 8:28 ` Ray Kinsella
2019-08-27 14:19 ` Ray Kinsella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190827081740.GB1740@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=mdr@ashroe.eu \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).