DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: 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:08:04 +0100	[thread overview]
Message-ID: <20190528120804.GA1095@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20190528115158.73245-1-ray.kinsella@intel.com>

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

  parent reply	other threads:[~2019-05-28 12:08 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 ` Bruce Richardson [this message]
2019-05-28 12:58   ` [dpdk-dev] [PATCH 0/2] Add ABI Version Testing to app/test Ray Kinsella
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=20190528120804.GA1095@bricha3-MOBL.ger.corp.intel.com \
    --to=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).