DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Ray Kinsella <ray.kinsella@intel.com>
Cc: vladimir.medvedkin@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/2] Add ABI Version Testing to app/test
Date: Tue, 28 May 2019 13:58:00 +0100	[thread overview]
Message-ID: <9e15f41d-f461-dbb8-d950-bfbe30422c62@ashroe.eu> (raw)
In-Reply-To: <20190528120804.GA1095@bricha3-MOBL.ger.corp.intel.com>

Hi Bruce,

There was a bit of a misfire on the patch submission - it came from the
wrong email a/c and the ML (rightly) rejected it.

Let me submit the patch properly and the feedback can begin in earnest then.

Ray K

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.
> 
> 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
> 

  reply	other threads:[~2019-05-28 12:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 11:51 Ray Kinsella
2019-05-28 11:51 ` [dpdk-dev] [PATCH 1/2] app/test: Add ABI Version Testing functionality Ray Kinsella
2019-05-28 11:51 ` [dpdk-dev] [PATCH 2/2] app/test: LPMv4 ABI Version Testing Ray Kinsella
2019-05-29 13:50   ` Aaron Conole
2019-05-28 12:08 ` [dpdk-dev] [PATCH 0/2] Add ABI Version Testing to app/test Bruce Richardson
2019-05-28 12:58   ` Ray Kinsella [this message]
2019-05-28 14:01   ` 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=9e15f41d-f461-dbb8-d950-bfbe30422c62@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ray.kinsella@intel.com \
    --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).