[dpdk-dev] Further fun with ABI tracking

[dpdk-dev] Further fun with ABI tracking

[Christian Ehrhardt]

Hi,
when moving to DPDK 16.11 Debian/Ubuntu packaging of DPDK has hit a new
twist on the (it seems reoccurring) topic of DPDK ABI tracking.

I have found, ... well I don't want to call it solution ..., let's say a
crutch to get around it for the moment. But I wanted to use the example I
had to share a few thoughts on it and to kick off a wider discussion.


*## In library cross-dependencies plus partial ABI bumps ##*

Since the day moving away from the combined shared library we had several
improvements on tracking the ABI versions. These days [1] we have LIBABIVER
per library and it gets bumped to reflect it is breaking with former
versions e.g. removing symbols.

Now in the 16.11 release the ABIs for cryptodev, eal and ethdev got bumped
by [2] and [3].

OTOH please remember that in general two versions of a shared library in
the usual sense are meant to be able to stay alongside on a system without
hurting each other. I picked a random one on my system.
Package              Library
libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160
libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160.0.0
libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95
libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95.5.0
Some link against the new, some against the old library - all fine.
Usually most programs can just be rebuilt against the new library and after
some time the old one can be dropped. That mechanism gives downstream
distributions a way to handle transitions and consumers of libraries which
might not all be ready for the same version every time.
And since the per lib versioning with LIBABIVER and and the version maps we
are good - in fact we qualify for all common cases on [4].

Now in DPDK of those libraries that got an ABI bump eal and ethdev are part
of those which most of us consider "core libraries" and most other libs and
pmds link to them.
And here DPDK continues to be special, due to that inter-dependency with
old and new libraries installed on the same system the following happens on
openvswitch built for an older version of dpdk:
ovs-vswitchd-dpdk
    librte_eal.so.2 => /usr/lib/x86_64-linux-gnu/librte_eal.so.2
    librte_pdump.so.1 => /usr/lib/x86_64-linux-gnu/librte_pdump.so.1
        librte_eal.so.3 => /usr/lib/x86_64-linux-gnu/librte_eal.so.3

You can see that Openvswitch itself depends on the "old" librte_eal.so.2.
But because  librte_pdump.so.1 did not get an ABI bump it got upgraded to
the newer version from DPDK 16.11.
But since the "new" pdump got built with the new DPDK 16.11 it depends on
the "new" librte_eal.so.3.
And having both in the same executable space at the same time causes
segfaults and pain.

As I said for now I have passed the issue with a crutch that I'm not proud
of and I'd like to avoid in the future. For that I'm reaching out to you
with several suggestions to discuss.


*## Thoughts ##*
None of these seems like a perfect solution to me yet, but clearly good to
start discussions on them.

Options that were in discussion so far and that we might adopt next cycle
(some of these are upstream changes, some downstream, some require both to
change - but any of them should have an ack upstream so that we are
agreeing how to proceed with those cases).

1. Downstreams to insert Major version into soname
Distributions could insert the DPDK major version (like 16.11) into the
soname and package names. A common example of this is libboost [5].
That would perfectly allow 16.07.<LIBABIVER> to coexist with
16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
Yet it would mean that anything depending on the old library will have to
be recompiled to pick up the new code, even if it depends on an ABI that is
still present in the new release.
Also - not a technical reason - but it is clearly more work to force update
all dependencies and clean out old packages for every release.


2. ABI Ranges
One could argue that due to the detailed tracking of functions DPDK is
already close to track not ABI levels but actually ABI ranges. DPDK could
track LIBABIVERMIN and LIBABIVER.
Every time functionality is added LIBABIVER would get bumped, but
LIBABIVERMIN only gets moved to the OLDEST still supported ABI when things
are dropped.
So on a given library librte_foo you could have LIBABIVER=5 and
LIBABIVERMIN=3. The make install would then install the shared lib as:
librte_foo.so.5
and additionally links for all compatible versions:
librte_foo.so.3 -> librte_foo.so.5
librte_foo.so.4 -> librte_foo.so.5
Yet, while is has some nice attributes this might make DPDK even more
special and cause ABI level proliferation over time.
Also even with this in place, changes moving LIBABIVERMIN "too fast" (too
fast is different for each downstream) could still cause an issue like the
one I initially described.


3. A lot of conflicts
In packaging one can declare a package to conflict with another package [6].
Now we could declare e.g. librte_eal3 to conflict with librte_eal2 (and the
same for all other bumps).
That would make them not coinstallable, and working on a new release would
mean that all former consumers would become not installable as well and
have to be rebuilt before they all could migrate [7] together.
That "works" in some sense, but it denies the whole purpose of versioned
library packages (to be coninstallable, to allow different library
consumers to depent on different versions)


4. ABI bump is infecting
Another way might be to also bump any dependent DPDK library.
So when core libs like eal are ABI bumped likely all libs would get a bump.
If only e.g. mempool gets a bump only those other parts using it would be
bumped as well.
To some extend this might still proliferate ABI versions more than one
would like.
Also it surely is hard to track if not automated - think of dependencies
that are existing only in certain config cases.

5. back to single ABI
For the sake of giving everybody a chance to re-open old wounds I wanted to
mention that DPDK could also decide to go back to a single ABI again.
This could (but doesn't have to!) be combined with having a single .so file
again.
To decide for this might be a much cleaner and easier to track way to #4.

6. More
I'm sure there are more approaches to this, feel free to come up with more.

I'm sure my five suggestions alone will make the thread messy, Maybe we do
this in two rounds, sorting out the insane and identifying the preferred
ones to then in a second run focus on discussing and maybe implementing the
details of what we like.


[1]: http://dpdk.org/browse/dpdk/tree/doc/guides/contributing/versioning.rst
[2]: http://dpdk.org/browse/dpdk/commit/?id=d7e61ad3ae36
[3]: http://dpdk.org/browse/dpdk/commit/?id=6ba1affa54108
[4]: https://wiki.debian.org/TransitionBestPractices
[5]: https://packages.debian.org/sid/libboost1.62-dev
[6]:
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[7]: https://wiki.ubuntu.com/ProposedMigration

P.S. I beg a pardon for the wall of text

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] Further fun with ABI tracking

[Bruce Richardson]

On Tue, Feb 14, 2017 at 11:52:00AM +0100, Christian Ehrhardt wrote:
> Hi,
> when moving to DPDK 16.11 Debian/Ubuntu packaging of DPDK has hit a new
> twist on the (it seems reoccurring) topic of DPDK ABI tracking.
> 
> I have found, ... well I don't want to call it solution ..., let's say a
> crutch to get around it for the moment. But I wanted to use the example I
> had to share a few thoughts on it and to kick off a wider discussion.
> 
> 
> *## In library cross-dependencies plus partial ABI bumps ##*
> 
> Since the day moving away from the combined shared library we had several
> improvements on tracking the ABI versions. These days [1] we have LIBABIVER
> per library and it gets bumped to reflect it is breaking with former
> versions e.g. removing symbols.
> 
> Now in the 16.11 release the ABIs for cryptodev, eal and ethdev got bumped
> by [2] and [3].
> 
> OTOH please remember that in general two versions of a shared library in
> the usual sense are meant to be able to stay alongside on a system without
> hurting each other. I picked a random one on my system.
> Package              Library
> libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160
> libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160.0.0
> libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95
> libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95.5.0
> Some link against the new, some against the old library - all fine.
> Usually most programs can just be rebuilt against the new library and after
> some time the old one can be dropped. That mechanism gives downstream
> distributions a way to handle transitions and consumers of libraries which
> might not all be ready for the same version every time.
> And since the per lib versioning with LIBABIVER and and the version maps we
> are good - in fact we qualify for all common cases on [4].
> 
> Now in DPDK of those libraries that got an ABI bump eal and ethdev are part
> of those which most of us consider "core libraries" and most other libs and
> pmds link to them.
> And here DPDK continues to be special, due to that inter-dependency with
> old and new libraries installed on the same system the following happens on
> openvswitch built for an older version of dpdk:
> ovs-vswitchd-dpdk
>     librte_eal.so.2 => /usr/lib/x86_64-linux-gnu/librte_eal.so.2
>     librte_pdump.so.1 => /usr/lib/x86_64-linux-gnu/librte_pdump.so.1
>         librte_eal.so.3 => /usr/lib/x86_64-linux-gnu/librte_eal.so.3
> 
> You can see that Openvswitch itself depends on the "old" librte_eal.so.2.
> But because  librte_pdump.so.1 did not get an ABI bump it got upgraded to
> the newer version from DPDK 16.11.
> But since the "new" pdump got built with the new DPDK 16.11 it depends on
> the "new" librte_eal.so.3.
> And having both in the same executable space at the same time causes
> segfaults and pain.
> 
> As I said for now I have passed the issue with a crutch that I'm not proud
> of and I'd like to avoid in the future. For that I'm reaching out to you
> with several suggestions to discuss.
> 
> 
> *## Thoughts ##*
> None of these seems like a perfect solution to me yet, but clearly good to
> start discussions on them.
> 
> Options that were in discussion so far and that we might adopt next cycle
> (some of these are upstream changes, some downstream, some require both to
> change - but any of them should have an ack upstream so that we are
> agreeing how to proceed with those cases).
> 
> 1. Downstreams to insert Major version into soname
> Distributions could insert the DPDK major version (like 16.11) into the
> soname and package names. A common example of this is libboost [5].
> That would perfectly allow 16.07.<LIBABIVER> to coexist with
> 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
> Yet it would mean that anything depending on the old library will have to
> be recompiled to pick up the new code, even if it depends on an ABI that is
> still present in the new release.
> Also - not a technical reason - but it is clearly more work to force update
> all dependencies and clean out old packages for every release.
> 
> 
> 2. ABI Ranges
> One could argue that due to the detailed tracking of functions DPDK is
> already close to track not ABI levels but actually ABI ranges. DPDK could
> track LIBABIVERMIN and LIBABIVER.
> Every time functionality is added LIBABIVER would get bumped, but
> LIBABIVERMIN only gets moved to the OLDEST still supported ABI when things
> are dropped.
> So on a given library librte_foo you could have LIBABIVER=5 and
> LIBABIVERMIN=3. The make install would then install the shared lib as:
> librte_foo.so.5
> and additionally links for all compatible versions:
> librte_foo.so.3 -> librte_foo.so.5
> librte_foo.so.4 -> librte_foo.so.5
> Yet, while is has some nice attributes this might make DPDK even more
> special and cause ABI level proliferation over time.
> Also even with this in place, changes moving LIBABIVERMIN "too fast" (too
> fast is different for each downstream) could still cause an issue like the
> one I initially described.
> 
> 
> 3. A lot of conflicts
> In packaging one can declare a package to conflict with another package [6].
> Now we could declare e.g. librte_eal3 to conflict with librte_eal2 (and the
> same for all other bumps).
> That would make them not coinstallable, and working on a new release would
> mean that all former consumers would become not installable as well and
> have to be rebuilt before they all could migrate [7] together.
> That "works" in some sense, but it denies the whole purpose of versioned
> library packages (to be coninstallable, to allow different library
> consumers to depent on different versions)
> 
> 
> 4. ABI bump is infecting
> Another way might be to also bump any dependent DPDK library.
> So when core libs like eal are ABI bumped likely all libs would get a bump.
> If only e.g. mempool gets a bump only those other parts using it would be
> bumped as well.
> To some extend this might still proliferate ABI versions more than one
> would like.
> Also it surely is hard to track if not automated - think of dependencies
> that are existing only in certain config cases.
> 
> 5. back to single ABI
> For the sake of giving everybody a chance to re-open old wounds I wanted to
> mention that DPDK could also decide to go back to a single ABI again.
> This could (but doesn't have to!) be combined with having a single .so file
> again.
> To decide for this might be a much cleaner and easier to track way to #4.
> 
> 6. More
> I'm sure there are more approaches to this, feel free to come up with more.
> 
> I'm sure my five suggestions alone will make the thread messy, Maybe we do
> this in two rounds, sorting out the insane and identifying the preferred
> ones to then in a second run focus on discussing and maybe implementing the
> details of what we like.
> 
> 

Of the 5 options you propose, No 4 looks most appealing to me. If it
does cause problems with different config cases, then that looks a good
reason to cut down on the allowed configs. :-)

/Bruce

> [1]: http://dpdk.org/browse/dpdk/tree/doc/guides/contributing/versioning.rst
> [2]: http://dpdk.org/browse/dpdk/commit/?id=d7e61ad3ae36
> [3]: http://dpdk.org/browse/dpdk/commit/?id=6ba1affa54108
> [4]: https://wiki.debian.org/TransitionBestPractices
> [5]: https://packages.debian.org/sid/libboost1.62-dev
> [6]:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
> [7]: https://wiki.ubuntu.com/ProposedMigration
> 
> P.S. I beg a pardon for the wall of text
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

Re: [dpdk-dev] Further fun with ABI tracking

[Jan Blunck]

On Tue, Feb 14, 2017 at 11:52 AM, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Hi,
> when moving to DPDK 16.11 Debian/Ubuntu packaging of DPDK has hit a new
> twist on the (it seems reoccurring) topic of DPDK ABI tracking.
>
> I have found, ... well I don't want to call it solution ..., let's say a
> crutch to get around it for the moment. But I wanted to use the example I
> had to share a few thoughts on it and to kick off a wider discussion.
>
>
> *## In library cross-dependencies plus partial ABI bumps ##*
>
> Since the day moving away from the combined shared library we had several
> improvements on tracking the ABI versions. These days [1] we have LIBABIVER
> per library and it gets bumped to reflect it is breaking with former
> versions e.g. removing symbols.
>
> Now in the 16.11 release the ABIs for cryptodev, eal and ethdev got bumped
> by [2] and [3].
>
> OTOH please remember that in general two versions of a shared library in
> the usual sense are meant to be able to stay alongside on a system without
> hurting each other. I picked a random one on my system.
> Package              Library
> libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160
> libisc-export160: /lib/x86_64-linux-gnu/libisc-export.so.160.0.0
> libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95
> libisc-export95: /lib/x86_64-linux-gnu/libisc-export.so.95.5.0
> Some link against the new, some against the old library - all fine.
> Usually most programs can just be rebuilt against the new library and after
> some time the old one can be dropped. That mechanism gives downstream
> distributions a way to handle transitions and consumers of libraries which
> might not all be ready for the same version every time.
> And since the per lib versioning with LIBABIVER and and the version maps we
> are good - in fact we qualify for all common cases on [4].
>
> Now in DPDK of those libraries that got an ABI bump eal and ethdev are part
> of those which most of us consider "core libraries" and most other libs and
> pmds link to them.
> And here DPDK continues to be special, due to that inter-dependency with
> old and new libraries installed on the same system the following happens on
> openvswitch built for an older version of dpdk:
> ovs-vswitchd-dpdk
>     librte_eal.so.2 => /usr/lib/x86_64-linux-gnu/librte_eal.so.2
>     librte_pdump.so.1 => /usr/lib/x86_64-linux-gnu/librte_pdump.so.1
>         librte_eal.so.3 => /usr/lib/x86_64-linux-gnu/librte_eal.so.3
>
> You can see that Openvswitch itself depends on the "old" librte_eal.so.2.
> But because  librte_pdump.so.1 did not get an ABI bump it got upgraded to
> the newer version from DPDK 16.11.
> But since the "new" pdump got built with the new DPDK 16.11 it depends on
> the "new" librte_eal.so.3.
> And having both in the same executable space at the same time causes
> segfaults and pain.
>
> As I said for now I have passed the issue with a crutch that I'm not proud
> of and I'd like to avoid in the future. For that I'm reaching out to you
> with several suggestions to discuss.
>
>
> *## Thoughts ##*
> None of these seems like a perfect solution to me yet, but clearly good to
> start discussions on them.
>
> Options that were in discussion so far and that we might adopt next cycle
> (some of these are upstream changes, some downstream, some require both to
> change - but any of them should have an ack upstream so that we are
> agreeing how to proceed with those cases).
>
> 1. Downstreams to insert Major version into soname
> Distributions could insert the DPDK major version (like 16.11) into the
> soname and package names. A common example of this is libboost [5].
> That would perfectly allow 16.07.<LIBABIVER> to coexist with
> 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
> Yet it would mean that anything depending on the old library will have to
> be recompiled to pick up the new code, even if it depends on an ABI that is
> still present in the new release.
> Also - not a technical reason - but it is clearly more work to force update
> all dependencies and clean out old packages for every release.

Actually this isn't exactly what I proposed during the summit. Just
keep it simple and fix the ABI version of all libraries at 16.11.0.
This is a proven approach and has been used for years with different
libraries. You could easily do this independently of us upstream
fixing the ABI problems.


> 2. ABI Ranges

ABI is either backwards compatible (same major) or not. A range
doesn't solve the problem.

>
> 3. A lot of conflicts
>

This doesn't allow us to have multiple version of the library
available at runtime. So in the end it doesn't solve the problem for
the distro either.


>
> 4. ABI bump is infecting
>
> 5. back to single ABI
>

This is very similar to approach 1. It just uses up a lot more ABI versions.


> 6. More
> I'm sure there are more approaches to this, feel free to come up with more.
>

The problem is that we do not detect and fix the ABI changes that
"shine-through" the dependencies of our libraries. We need to work on
them and fix them one by one. Long-term we need to invest into keeping
the API/ABI stable and adding backward compatible symbols as well as
making structures opaque.



> I'm sure my five suggestions alone will make the thread messy, Maybe we do
> this in two rounds, sorting out the insane and identifying the preferred
> ones to then in a second run focus on discussing and maybe implementing the
> details of what we like.
>
>
> [1]: http://dpdk.org/browse/dpdk/tree/doc/guides/contributing/versioning.rst
> [2]: http://dpdk.org/browse/dpdk/commit/?id=d7e61ad3ae36
> [3]: http://dpdk.org/browse/dpdk/commit/?id=6ba1affa54108
> [4]: https://wiki.debian.org/TransitionBestPractices
> [5]: https://packages.debian.org/sid/libboost1.62-dev
> [6]:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
> [7]: https://wiki.ubuntu.com/ProposedMigration
>
> P.S. I beg a pardon for the wall of text
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

Re: [dpdk-dev] Further fun with ABI tracking

[Christian Ehrhardt]

On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck <jblunck@infradead.org> wrote:

> > 1. Downstreams to insert Major version into soname
> > Distributions could insert the DPDK major version (like 16.11) into the
> > soname and package names. A common example of this is libboost [5].
> > That would perfectly allow 16.07.<LIBABIVER> to coexist with
> > 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
> > Yet it would mean that anything depending on the old library will have to
> > be recompiled to pick up the new code, even if it depends on an ABI that
> is
> > still present in the new release.
> > Also - not a technical reason - but it is clearly more work to force
> update
> > all dependencies and clean out old packages for every release.
>
> Actually this isn't exactly what I proposed during the summit. Just
> keep it simple and fix the ABI version of all libraries at 16.11.0.
> This is a proven approach and has been used for years with different
> libraries.


Since there was no other response I'll try to wrap up.

Yes #1 also is my preferred solution at the moment.
We tried with individual following the tracking of LIBABIVER upstream but
as outlined before we hit too many issues.
I discussed it in the deb_dpdk group which acked as well to use this as
general approach.
The other options have too obvious flaws as I listed on my initial report
and - thanks btw - you added a few more.

@Bruce - sorry I don't think dropping config options is the solution. Yet
my suggestion does not prevent you from doing so.



> You could easily do this independently of us upstream
> fixing the ABI problems.



I agree, but I'd like to suggest the mechanism I want to implement.
An ack by upstream for the Feature to set such a major ABI would be great.
Actually since it is optional and can help more people integrating DPDK
getting it accepted upstream be even better.

I'll send a patch in reply to this thread later today that implements what
I have in mind.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[dpdk-dev] [PATCH] mk: Provide option to set Major ABI version

[Christian Ehrhardt]

Downstreams might want to provide different DPDK releases at the same
time to support multiple consumers of DPDK linked against older and newer
sonames.

Also due to the interdependencies that DPDK libraries can have applications
might end up with an executable space in which multiple versions of a
library are mapped by ld.so.

Think of LibA that got an ABI bump and LibB that did not get an ABI bump
but is depending on LibA.

    Application
    \-> LibA.old
    \-> LibB.new -> LibA.new

That is a conflict which can be avoided by setting CONFIG_RTE_MAJOR_ABI.
If set CONFIG_RTE_MAJOR_ABI overwrites any LIBABIVER value.
An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all
libraries librte<?>.so.16.11 instead of librte<?>.so.<LIBABIVER>.

We need to cut arbitrary long stings after the .so now and this would work
for any ABI version in LIBABIVER:
  $(Q)ln -s -f $< $(patsubst %.$(LIBABIVER),%,$@)
But using the following instead additionally allows to simplify the Make
File for the CONFIG_RTE_NEXT_ABI case.
  $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
 config/common_base                     |  5 +++++
 doc/guides/contributing/versioning.rst | 25 +++++++++++++++++++++++++
 mk/rte.lib.mk                          | 12 +++++++-----
 3 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/config/common_base b/config/common_base
index aeee13e..37aa1e1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -75,6 +75,11 @@ CONFIG_RTE_BUILD_SHARED_LIB=n
 CONFIG_RTE_NEXT_ABI=y
 
 #
+# Major ABI to overwrite library specific LIBABIVER
+#
+CONFIG_RTE_MAJOR_ABI=
+
+#
 # Machine's cache line size
 #
 CONFIG_RTE_CACHE_LINE_SIZE=64
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index fbc44a7..8aaf370 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -133,6 +133,31 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
+Setting a Major ABI version
+---------------------------
+
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
+
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
+
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
+
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
 Examples of ABI Macro use
 -------------------------
 
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 33a5f5a..06046c2 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -40,6 +40,12 @@ EXTLIB_BUILD ?= n
 # VPATH contains at least SRCDIR
 VPATH += $(SRCDIR)
 
+ifneq ($(CONFIG_RTE_MAJOR_ABI),)
+ifneq ($(LIBABIVER),)
+LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
+endif
+endif
+
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
 LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
 ifeq ($(EXTLIB_BUILD),n)
@@ -156,11 +162,7 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
 	@[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
 	$(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-ifeq ($(CONFIG_RTE_NEXT_ABI)$(EXTLIB_BUILD),yn)
-	$(Q)ln -s -f $< $(basename $(basename $@))
-else
-	$(Q)ln -s -f $< $(basename $@)
-endif
+	$(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
 endif
 
 #
-- 
2.7.4

Re: [dpdk-dev] Further fun with ABI tracking

[Ferruh Yigit]

On 2/22/2017 1:12 PM, Christian Ehrhardt wrote:
> On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck <jblunck@infradead.org> wrote:
> 
>>> 1. Downstreams to insert Major version into soname
>>> Distributions could insert the DPDK major version (like 16.11) into the
>>> soname and package names. A common example of this is libboost [5].
>>> That would perfectly allow 16.07.<LIBABIVER> to coexist with
>>> 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
>>> Yet it would mean that anything depending on the old library will have to
>>> be recompiled to pick up the new code, even if it depends on an ABI that
>> is
>>> still present in the new release.
>>> Also - not a technical reason - but it is clearly more work to force
>> update
>>> all dependencies and clean out old packages for every release.
>>
>> Actually this isn't exactly what I proposed during the summit. Just
>> keep it simple and fix the ABI version of all libraries at 16.11.0.
>> This is a proven approach and has been used for years with different
>> libraries.
> 
> 
> Since there was no other response I'll try to wrap up.
> 
> Yes #1 also is my preferred solution at the moment.
> We tried with individual following the tracking of LIBABIVER upstream but
> as outlined before we hit too many issues.
> I discussed it in the deb_dpdk group which acked as well to use this as
> general approach.
> The other options have too obvious flaws as I listed on my initial report
> and - thanks btw - you added a few more.
> 
> @Bruce - sorry I don't think dropping config options is the solution. Yet
> my suggestion does not prevent you from doing so.

Hi Christian,

Can you please describe this option more?

Does is mean for each DPDK release, distro will release all libraries?

For 16.07:
acl.2, eal.2, ethdev.4, pdump.1

For 16.11:
acl.2, eal.3, ethdev.5, pdump.1

Will dpdk package have following packages:
acl.16.07.2, eal.16.07.2, ethdev.16.07.4, pdump.16.07.1
acl.16.11.2, eal.16.11.3, ethdev.16.11.5, pdump.16.11.1

And for initial OVS usecase, will it be:

OVS
 +---> eal.16.07.2
 +---> pdump.16.11.1
        +---> eal.16.11.3


Assuming above understanding is correct J :

- If same version of the library will be delivered for each DPDK
release, what is the benefit of having fine grained libraries really?

- Above OVS usage still does not look right, I don't believe this is the
intention when library level dependency resolving introduced.

Overall I am for single library, but I can see the benefit of having
multiple small libraries, that is why I vote for option 4 in your
initial mail.

And I agree this can cause problem if not automated, but we already know
the library dependencies, I think a script can be developed to warn a
least, and they can be updated manually.

And isn't the purpose of increasing LIBABIVER to notify application that
library is modified and can't be used with that app anymore.
For DPDK, even if the library is not changed, if another library that it
depends modified, this may mean the behavior of the library may be
changed, so it makes sense to me if library notifies the user for this
case, by increasing its version.

Yes this makes effect of increasing a core library version big, but I
believe this is also true, increasing a core library version almost
means increasing dpdk version.

> 
> 
> 
>> You could easily do this independently of us upstream
>> fixing the ABI problems.
> 
> 
> 
> I agree, but I'd like to suggest the mechanism I want to implement.
> An ack by upstream for the Feature to set such a major ABI would be great.
> Actually since it is optional and can help more people integrating DPDK
> getting it accepted upstream be even better.
> 
> I'll send a patch in reply to this thread later today that implements what
> I have in mind.
> 
> 

Re: [dpdk-dev] Further fun with ABI tracking

[Christian Ehrhardt]

On Thu, Feb 23, 2017 at 7:48 PM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:

> Can you please describe this option more?
>

Of course, I happy about any engagement/discussion to have on that.
Much better than silently staying in queue.


> Does is mean for each DPDK release, distro will release all libraries?
>

First of all it is opt-in. If nobody does change the default setting (="")
to
anything nothing happens.

A distribution _CAN_ use the feature to reliably avoid collisions between
DPDK releases and allow concurrent installations more easily.


> For 16.07:
> acl.2, eal.2, ethdev.4, pdump.1
>
> For 16.11:
> acl.2, eal.3, ethdev.5, pdump.1
>

That example is what we did so far, trying to follow the DPDK ABI
versioning.
But that caused the issue I described with (new)pdump.1->eal.3 and the base
app->eal2


Will dpdk package have following packages:
> acl.16.07.2, eal.16.07.2, ethdev.16.07.4, pdump.16.07.1
> acl.16.11.2, eal.16.11.3, ethdev.16.11.5, pdump.16.11.1
>

I thought on that, but Jan correctly brought up that if we do override we
should
as well trivialize and override fully - ignoring the per lib LIBABIVER.
So it will not be eal.16.11.3 but instead just eal.16.11   (no subversion,
as there
is no need). If that is wanted that can easily be done, please let me know
if I
should run a v2 with that.

And for initial OVS usecase, will it be:
>
> OVS
>  +---> eal.16.07.2
>  +---> pdump.16.11.1
>         +---> eal.16.11.3
>
>
Not quite, the usecase would look like that:
The current DPDK generates LIBABIVER versions: eal.3, pdump.1, ...
OVS
 +---> eal.3
 +---> pdump.1
        +---> eal.3

Note: Packages are initially carried forward from the former Distrobution
release,
so the next release would start as the former has ended:
OVS
 +---> eal.3
 +---> pdump.1
        +---> eal.3

Then the new DPDK would come in and using this feature would then
generate all as major version: eal.17.02, pdump.17.02, ...
But since OVS was not recompiled yet AND there is no collision OVS
would still look like:
OVS
 +---> eal.3
 +---> pdump.1
        +---> eal.3

Then we can recompile OVS and it will become
OVS
 +---> eal.17.02
 +---> pdump.17.02
        +---> eal.17.02

Into the future with more apps depending on DPDK there can be many
scenarios:
1. all are fine rebuilding, there will be no dependency left to the older
dpdk
    and it will be autoremoved after all upgrades
2. some packages are slow to adapt, but that is fine we can still provide
the
    old dependencies at the same time if needed
3. the time in between #2 and #1 is not wreaking havok as the
cross-dependency
    issue is no more


> Assuming above understanding is correct J :
>
> - If same version of the library will be delivered for each DPDK
> release, what is the benefit of having fine grained libraries really?
>

The benefit of the fine grained versioning is for other types of
distributing DPDK.
Recognizing an ABI bump for lib-consuming developers, bundling it directly
with your app, ...



> - Above OVS usage still does not look right, I don't believe this is the
> intention when library level dependency resolving introduced.
>
> Overall I am for single library, but I can see the benefit of having
> multiple small libraries, that is why I vote for option 4 in your
> initial mail.
>

Single library would solve it as well, but as mentioned and you all
remember there
were people with reasons for it that I could not challenge being too far
out of the
application scenarios they had in mind.

And I agree this can cause problem if not automated, but we already know
> the library dependencies, I think a script can be developed to warn a
> least, and they can be updated manually.
>
> And isn't the purpose of increasing LIBABIVER to notify application that
> library is modified and can't be used with that app anymore.
> For DPDK, even if the library is not changed, if another library that it
> depends modified, this may mean the behavior of the library may be
> changed, so it makes sense to me if library notifies the user for this
> case, by increasing its version.
>
> Yes this makes effect of increasing a core library version big, but I
> believe this is also true, increasing a core library version almost
> means increasing dpdk version.
>

Interesting - thanks for sharing your opinion here - I rethought that for a
while now.

While this could work I consider it inferior to the approach I submitted
in the patch yesterday [1] for the following reasons:

- If we bump infecting (looking at the recent history) we most likely end up
  bumping all libraries at least every other release. Now there isn't much
  different in bumping all of them +1 or just using a single increasing
version.
  Except you could miss a few bumps or track it wrong.

- The new Feature is opt-in, allowing those who want to do that major bump;
  But at the same time allowing those who won't to keep on tracking each lib
  individually and build/deliver it that way.

- I learned (often the hard way) that to be different often causes problems
  that are hard to foresee.
  The infecting ABI would be "DPDK is different" again, while the major
  override is somewhat established.

For now I'd suggest taking the opt-in feature as suggested in [1] as a means
for those who need it (like us and maybe more downstreams over time).
If DPDK is evolving to become more stable and develops a feature like
the #4 "infecting-abi-bump + tracking" it can still be picked us later and
by anybody else who wants needs it.
It will then "just" be dropping a config option we set before to get back.


TL;DR: I think DPDK is not stable enough to make option #4 worth
implementing for now to make a difference worth (but would cause
lot of work and error potential). But since my code [1] implementing
approach #1 and a later approach #4 in the future are not mutually
exclusive I'd ask to go for #1 now and #4 later if one needs and
implements it.

[1]: http://dpdk.org/ml/archives/dev/2017-February/058121.html


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [PATCH] mk: Provide option to set Major ABI version

[Jan Blunck]

On Wed, Feb 22, 2017 at 2:24 PM, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -40,6 +40,12 @@ EXTLIB_BUILD ?= n
>  # VPATH contains at least SRCDIR
>  VPATH += $(SRCDIR)
>
> +ifneq ($(CONFIG_RTE_MAJOR_ABI),)
> +ifneq ($(LIBABIVER),)
> +LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
> +endif
> +endif
> +
>  ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
>  LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
>  ifeq ($(EXTLIB_BUILD),n)
> @@ -156,11 +162,7 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
>         @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
>         $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
>  ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> -ifeq ($(CONFIG_RTE_NEXT_ABI)$(EXTLIB_BUILD),yn)
> -       $(Q)ln -s -f $< $(basename $(basename $@))
> -else
> -       $(Q)ln -s -f $< $(basename $@)
> -endif
> +       $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
>  endif
>

In case CONFIG_RTE_NEXT_ABI=y is set this is actually generating
shared objects with suffix:

  .so.$(CONFIG_RTE_MAJOR_ABI).1

I don't think that this is the intention.

Re: [dpdk-dev] [PATCH] mk: Provide option to set Major ABI version

[Christian Ehrhardt]

On Tue, Feb 28, 2017 at 9:34 AM, Jan Blunck <jblunck@infradead.org> wrote:

> In case CONFIG_RTE_NEXT_ABI=y is set this is actually generating
> shared objects with suffix:
>
>   .so.$(CONFIG_RTE_MAJOR_ABI).1
>
> I don't think that this is the intention.
>

You are right, thanks for the catch Jan!
The fix is a trivial extra ifeq - a V2 is on the way soon.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version

[Christian Ehrhardt]

Downstreams might want to provide different DPDK releases at the same
time to support multiple consumers of DPDK linked against older and newer
sonames.

Also due to the interdependencies that DPDK libraries can have applications
might end up with an executable space in which multiple versions of a
library are mapped by ld.so.

Think of LibA that got an ABI bump and LibB that did not get an ABI bump
but is depending on LibA.

    Application
    \-> LibA.old
    \-> LibB.new -> LibA.new

That is a conflict which can be avoided by setting CONFIG_RTE_MAJOR_ABI.
If set CONFIG_RTE_MAJOR_ABI overwrites any LIBABIVER value.
An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all
libraries librte<?>.so.16.11 instead of librte<?>.so.<LIBABIVER>.

We need to cut arbitrary long stings after the .so now and this would work
for any ABI version in LIBABIVER:
  $(Q)ln -s -f $< $(patsubst %.$(LIBABIVER),%,$@)
But using the following instead additionally allows to simplify the Make
File for the CONFIG_RTE_NEXT_ABI case.
  $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
 config/common_base                     |  5 +++++
 doc/guides/contributing/versioning.rst | 25 +++++++++++++++++++++++++
 mk/rte.lib.mk                          | 14 +++++++++-----
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/config/common_base b/config/common_base
index aeee13e..37aa1e1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -75,6 +75,11 @@ CONFIG_RTE_BUILD_SHARED_LIB=n
 CONFIG_RTE_NEXT_ABI=y
 
 #
+# Major ABI to overwrite library specific LIBABIVER
+#
+CONFIG_RTE_MAJOR_ABI=
+
+#
 # Machine's cache line size
 #
 CONFIG_RTE_CACHE_LINE_SIZE=64
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index fbc44a7..8aaf370 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -133,6 +133,31 @@ The macros exported are:
   fully qualified function ``p``, so that if a symbol becomes versioned, it
   can still be mapped back to the public symbol name.
 
+Setting a Major ABI version
+---------------------------
+
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
+
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
+
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
+
+.. note::
+
+    Application
+    \-> LibA.old
+    \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
 Examples of ABI Macro use
 -------------------------
 
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
index 33a5f5a..1ffbf42 100644
--- a/mk/rte.lib.mk
+++ b/mk/rte.lib.mk
@@ -40,12 +40,20 @@ EXTLIB_BUILD ?= n
 # VPATH contains at least SRCDIR
 VPATH += $(SRCDIR)
 
+ifneq ($(CONFIG_RTE_MAJOR_ABI),)
+ifneq ($(LIBABIVER),)
+LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
+endif
+endif
+
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
 LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
 ifeq ($(EXTLIB_BUILD),n)
+ifeq ($(CONFIG_RTE_MAJOR_ABI),)
 ifeq ($(CONFIG_RTE_NEXT_ABI),y)
 LIB := $(LIB).1
 endif
+endif
 CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
 endif
 endif
@@ -156,11 +164,7 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
 	@[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
 	$(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
 ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
-ifeq ($(CONFIG_RTE_NEXT_ABI)$(EXTLIB_BUILD),yn)
-	$(Q)ln -s -f $< $(basename $(basename $@))
-else
-	$(Q)ln -s -f $< $(basename $@)
-endif
+	$(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
 endif
 
 #
-- 
2.7.4

Re: [dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version

[Jan Blunck]

On Wed, Mar 1, 2017 at 10:34 AM, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
> Downstreams might want to provide different DPDK releases at the same
> time to support multiple consumers of DPDK linked against older and newer
> sonames.
>
> Also due to the interdependencies that DPDK libraries can have applications
> might end up with an executable space in which multiple versions of a
> library are mapped by ld.so.
>
> Think of LibA that got an ABI bump and LibB that did not get an ABI bump
> but is depending on LibA.
>
>     Application
>     \-> LibA.old
>     \-> LibB.new -> LibA.new
>
> That is a conflict which can be avoided by setting CONFIG_RTE_MAJOR_ABI.
> If set CONFIG_RTE_MAJOR_ABI overwrites any LIBABIVER value.
> An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all
> libraries librte<?>.so.16.11 instead of librte<?>.so.<LIBABIVER>.
>
> We need to cut arbitrary long stings after the .so now and this would work
> for any ABI version in LIBABIVER:
>   $(Q)ln -s -f $< $(patsubst %.$(LIBABIVER),%,$@)
> But using the following instead additionally allows to simplify the Make
> File for the CONFIG_RTE_NEXT_ABI case.
>   $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
>
> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> ---
>  config/common_base                     |  5 +++++
>  doc/guides/contributing/versioning.rst | 25 +++++++++++++++++++++++++
>  mk/rte.lib.mk                          | 14 +++++++++-----
>  3 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/config/common_base b/config/common_base
> index aeee13e..37aa1e1 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -75,6 +75,11 @@ CONFIG_RTE_BUILD_SHARED_LIB=n
>  CONFIG_RTE_NEXT_ABI=y
>
>  #
> +# Major ABI to overwrite library specific LIBABIVER
> +#
> +CONFIG_RTE_MAJOR_ABI=
> +
> +#
>  # Machine's cache line size
>  #
>  CONFIG_RTE_CACHE_LINE_SIZE=64
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index fbc44a7..8aaf370 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -133,6 +133,31 @@ The macros exported are:
>    fully qualified function ``p``, so that if a symbol becomes versioned, it
>    can still be mapped back to the public symbol name.
>
> +Setting a Major ABI version
> +---------------------------
> +
> +Downstreams might want to provide different DPDK releases at the same time to
> +support multiple consumers of DPDK linked against older and newer sonames.
> +
> +Also due to the interdependencies that DPDK libraries can have applications
> +might end up with an executable space in which multiple versions of a library
> +are mapped by ld.so.
> +
> +Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
> +depending on LibA.
> +
> +.. note::
> +
> +    Application
> +    \-> LibA.old
> +    \-> LibB.new -> LibA.new
> +
> +That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
> +If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
> +library - versions defined in the libraries ``LIBABIVER``.
> +An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
> +``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
> +
>  Examples of ABI Macro use
>  -------------------------
>
> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
> index 33a5f5a..1ffbf42 100644
> --- a/mk/rte.lib.mk
> +++ b/mk/rte.lib.mk
> @@ -40,12 +40,20 @@ EXTLIB_BUILD ?= n
>  # VPATH contains at least SRCDIR
>  VPATH += $(SRCDIR)
>
> +ifneq ($(CONFIG_RTE_MAJOR_ABI),)
> +ifneq ($(LIBABIVER),)
> +LIBABIVER := $(CONFIG_RTE_MAJOR_ABI)
> +endif
> +endif
> +
>  ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
>  LIB := $(patsubst %.a,%.so.$(LIBABIVER),$(LIB))
>  ifeq ($(EXTLIB_BUILD),n)
> +ifeq ($(CONFIG_RTE_MAJOR_ABI),)
>  ifeq ($(CONFIG_RTE_NEXT_ABI),y)
>  LIB := $(LIB).1
>  endif
> +endif
>  CPU_LDFLAGS += --version-script=$(SRCDIR)/$(EXPORT_MAP)
>  endif
>  endif
> @@ -156,11 +164,7 @@ $(RTE_OUTPUT)/lib/$(LIB): $(LIB)
>         @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib
>         $(Q)cp -f $(LIB) $(RTE_OUTPUT)/lib
>  ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
> -ifeq ($(CONFIG_RTE_NEXT_ABI)$(EXTLIB_BUILD),yn)
> -       $(Q)ln -s -f $< $(basename $(basename $@))
> -else
> -       $(Q)ln -s -f $< $(basename $@)
> -endif
> +       $(Q)ln -s -f $< $(shell echo $@ | sed 's/\.so.*/.so/')
>  endif
>
>  #
> --
> 2.7.4
>

Reviewed-by: Jan Blunck <jblunck@infradead.org>
Tested-by: Jan Blunck <jblunck@infradead.org>

Re: [dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version

[Thomas Monjalon]

2017-03-01 15:35, Jan Blunck:
> On Wed, Mar 1, 2017 at 10:34 AM, Christian Ehrhardt
> <christian.ehrhardt@canonical.com> wrote:
> > Downstreams might want to provide different DPDK releases at the same
> > time to support multiple consumers of DPDK linked against older and newer
> > sonames.
> >
> > Also due to the interdependencies that DPDK libraries can have applications
> > might end up with an executable space in which multiple versions of a
> > library are mapped by ld.so.
> >
> > Think of LibA that got an ABI bump and LibB that did not get an ABI bump
> > but is depending on LibA.
> >
> >     Application
> >     \-> LibA.old
> >     \-> LibB.new -> LibA.new
> >
> > That is a conflict which can be avoided by setting CONFIG_RTE_MAJOR_ABI.
> > If set CONFIG_RTE_MAJOR_ABI overwrites any LIBABIVER value.
> > An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all
> > libraries librte<?>.so.16.11 instead of librte<?>.so.<LIBABIVER>.
[...]
> >
> > Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> 
> Reviewed-by: Jan Blunck <jblunck@infradead.org>
> Tested-by: Jan Blunck <jblunck@infradead.org>

Not sure about how it can be used in distributions, but it does not hurt
to provide the config option.
Are you going to link applications against a fixed DPDK version for
every libraries?

Applied, thanks

Re: [dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version

[Christian Ehrhardt]

On Thu, Mar 16, 2017 at 6:19 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> Not sure about how it can be used in distributions, but it does not hurt
> to provide the config option.
> Are you going to link applications against a fixed DPDK version for
> every libraries?
>

Kind of yes - we can still update "inside" a major version e.g. stable
releases just fine.
That helps a lot transitioning from one to the next release.

I have an RFC patch for the Debian packaging making use of it this function
that we will likely refresh and pick up on our next merge of a DPDK version.
And I already heard that even other downstreams are using it to simplify
their dependencies.

Applied, thanks
>

Thanks !


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [PATCH v2] mk: Provide option to set Major ABI version

[Jan Blunck]

On Fri, Mar 17, 2017 at 9:27 AM, Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Thu, Mar 16, 2017 at 6:19 PM, Thomas Monjalon <thomas.monjalon@6wind.com>
> wrote:
>>
>> Not sure about how it can be used in distributions, but it does not hurt
>> to provide the config option.
>> Are you going to link applications against a fixed DPDK version for
>> every libraries?
>
>
> Kind of yes - we can still update "inside" a major version e.g. stable
> releases just fine.
> That helps a lot transitioning from one to the next release.

Exactly. It enables me to roll out a new major release without being
blocked on the (external) consumers to pick up the changes. Now I can
do this one by one with reduced risk because the runtimes are clearly
separated.

> And I already heard that even other downstreams are using it to simplify
> their dependencies.
>

Downstream?! Pha! ;)