On 2016-11-19 22:54, Maxim Uvarov wrote: > Anders, > > can you please send proposal patch for changing versions? I think it will be > more easy to discuss it if we will have some working patch. > > I also looked to numbering issue one more time and think that it will be > good to have version in both abi and not abi compact library. > > Our original version numbers in shipped files are: > dynamic: > libodp-linux.so -> libodp-linux.so.111.0.0 > libodp-linux.so.111 -> libodp-linux.so.111.0.0 > libodp-linux.so.111.0.0 > static: > libodp-linux.a > > > After reset it will be: > dynamic: > libodp-linux.so -> libodp-linux.so.0.0.0 > libodp-linux.so.0 -> libodp-linux.so.0.0.0 > libodp-linux.so.0.0.0 > static: > libodphelper-linux.a > > Reset I think you asked for such change: > --- a/configure.ac > +++ b/configure.ac > @@ -245,6 +245,12 @@ AC_ARG_ENABLE([abi-compat], > [if test "x$enableval" = "xyes"; then > ODP_ABI_COMPAT=1 > abi_compat=yes > + > + # Reset library versions > + ODP_LIBSO_VERSION=0:0:0 > + AC_SUBST(ODP_LIBSO_VERSION) > + ODPHELPER_LIBSO_VERSION=0:0:0 > + AC_SUBST(ODPHELPER_LIBSO_VERSION)
This should be after else if we want this. > else > ODP_ABI_COMPAT=0 > abi_compat=no Instead of resetting the SO-version to 0:0:0 maybe we should just not produce the shared libs? Something like this: AC_ENABLE_SHARED(no) Cheers, Anders > > For both static and dynamic libraries API version will be reported as > previous but .so version will be different. > > I think that it might be useful for debugging to see from which exactly > version is used in file system. And more > logically abi compat so should have name libodp-linux.so and non abi compat > libodp-linux-generic.so. And keep > all their numbers. In that case Cavium, Freescale, Odp-dpdk also sheep > libodp-linux.so in abi compat mode and > some other library name is non compat mode. (I.e. abi compat application > uses libodp-linux.so on any platforms, > and non abi application uses libodp-linux-plat.so only on platform where it > was compiled.). > > What do you think? > > Thank you, > Maxim. > > > On 11/18/16 22:52, Anders Roxell wrote: > >On 18 November 2016 at 01:34, Bill Fischofer <bill.fischo...@linaro.org> > >wrote:libodp-linux.so.111.0.0 > >>Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org> > >>--- > >>Changes for v2: > >>- Changed release level to v1.11.1.0 per Mike > >> > >> CHANGELOG | 211 > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 211 insertions(+) > >> > >>diff --git a/CHANGELOG b/CHANGELOG > >>index d8230cd..66488e5 100644 > >>--- a/CHANGELOG > >>+++ b/CHANGELOG > >>@@ -1,3 +1,214 @@ > >>+== OpenDataPlane (1.11.1.0) > >>+ > >>+=== New Features > >>+ > >>+==== APIs > >>+ODP v1.11.1.0 is a minor API revision level beyond the Monarch Long Term > >>+Support (LTS) release and introduces a small change to the Traffic Manager > >>API > >>+as well as some documentation clarification surrounding other APIs. > >>+ > >>+==== Traffic Manager Egress Function > >>+The `odp_tm_egress_t` struct has been changed to add an explicit Boolean > >>+(`egress_fcn_supported`) that indicates whether the TM system supports > >>+a user-provided egress function. When specified this function is called to > >>+"output" a packet rather than having TM transmit it directly to a PktIO > >>+interface. > >>+ > >>+==== Traffic Manager Coupling Change > >>+The `odp_tm_egress_t` struct has been changed to associate a TM system > >>with an > >>+output `odp_pktio_t` rather than the previous `odp_pktout_queue_t`. This > >>makes > >>+an explicit 1-to-1 map between a TM system and a PktIO interface. > >This means that we should bump the ODP's SO-version as well, since > >we changed the struct that you mention + that we added "odp_bool_t > >egress_fcn_supported;" to the same struct. > > > >>+ > >>+==== Default huge page size clarification > >>+The documentation for the `odp_sys_huge_page_size()` API has been reworded > >>to > >>+clarify that this API refers to default huge page size. > >>+ > >>+==== Strict Priority (SP) Scheduler > >>+Building on the modular scheduler framework added in v1.10.1.0, an > >>alternate > >>+Strict Priority (SP) Scheduler is now available for latency-sensitive > >>+workloads. Applications wishing to use the SP scheduler should specify > >>+the `./configure` option `--enable-schedule-sp`. This scheduler emphasizes > >>low > >>+latency processing of high priority events at the expense of throughput. > >>This > >>+alternate scheduler is considered experimental and should not be used for > >>+production at this time. > >>+ > >>+==== Application Binary Interface (ABI) Support > >>+Support is added to enable ODP applications to be binary compatible across > >>+different implementations of ODP sharing the same Instruction Set > >>Architecture > >>+(ISA). This support introduces a new `configure` option: > >>+ > >>+`--enable-abi-compat=yes`:: > >>+This is the default and specifies that the ODP library is to be built to > >>+support ABI compatibility mode. In this mode ODP APIs are never inlined. > >>ABI > >>+compatibility ensures maximum application portability in cloud > >>environments. > >>+ > >>+`--enable-abi-compat=no`:: > >>+Specify this option to enable the inlining of ODP APIs. This may result in > >>+improved performance at the cost of ABI compatibility and is suitable for > >>+applications running in embedded environments. > >before we do a new release I think we need to resolve what we > >talked about in this thread [1]. > >Basically, if we disable ABI compat mode I think we should set the > >SO-version to 0:0:0, to make it clear that we don't try to be ABI > >compatible. > > > >Cheers, > >Anders > >[1] https://lists.linaro.org/pipermail/lng-odp/2016-September/025734.html > > > >>+ > >>+Note that ODP applications retain source code portability between ODP > >>+implementations regardless of the ABI mode chosen. To move to a different > >>ODP > >>+application running on a different ISA, code need simply be recompiled > >>against > >>+that target ODP implementation. > >>+ > >>+==== SCTP Parsing Support > >>+The ODP classifier adds support for recognizing Stream Control Transmission > >>+Protocol (SCTP) packets. The APIs for this were previously not implemented. > >>+ > >>+=== Packaging and Implementation Refinements > >>+ > >>+==== Remove dependency on Linux headers > >>+ODP no longer has a dependency on Linux headers. This will help make the > >>+odp-linux reference implementation more easily portable to non-Linux > >>+environments. > >>+ > >>+==== Remove dependency on helpers > >>+The odp-linux implementation has been made independent of the helper > >>library > >>+to avoid circular dependency issues with packaging. Helper functions may > >>use > >>+ODP APIs, however ODP implementations should not use helper functions. > >>+ > >>+==== Reorganization of `test` directory > >>+The `test` directory has been reorganized to better support a unified > >>approach > >>+to ODP component testing. API tests now live in > >>+`test/common_plat/validation/api` instead of the former > >>+`test/validation`. With this change performance and validation tests, as > >>well > >>+as common and platform-specific tests can all be part of a unified test > >>+hierarchy. > >>+ > >>+The resulting test tree now looks like: > >>+ > >>+.New `test` directory hierarchy > >>+----- > >>+test > >>+├── common_plat > >>+│ ├── common > >>+│ ├── m4 > >>+│ ├── miscellaneous > >>+│ ├── performance > >>+│ └── validation > >>+│ └── api > >>+│ ├── atomic > >>+│ ├── barrier > >>+│ ├── buffer > >>+│ ├── classification > >>+│ ├── cpumask > >>+│ ├── crypto > >>+│ ├── errno > >>+│ ├── hash > >>+│ ├── init > >>+│ ├── lock > >>+│ ├── packet > >>+│ ├── pktio > >>+│ ├── pool > >>+│ ├── queue > >>+│ ├── random > >>+│ ├── scheduler > >>+│ ├── shmem > >>+│ ├── std_clib > >>+│ ├── system > >>+│ ├── thread > >>+│ ├── time > >>+│ ├── timer > >>+│ └── traffic_mngr > >>+├── linux-generic > >>+│ ├── m4 > >>+│ ├── mmap_vlan_ins > >>+│ ├── performance > >>+│ ├── pktio_ipc > >>+│ ├── ring > >>+│ └── validation > >>+│ └── api > >>+│ ├── pktio > >>+│ └── shmem > >>+└── m4 > >>+----- > >>+ > >>+==== Pools > >>+The maximum number of pools that may be created in the odp-linux reference > >>+implementation has been raised from 16 to 64. > >>+ > >>+==== Upgrade to DPDK 16.07 > >>+The DPDK pktio support in odp-linux has been upgraded to work with DPDK > >>16.07. > >>+A number of miscellaneous fixes and performance improvements in this > >>support > >>+are also present. > >>+ > >>+==== PktIO TAP Interface Classifier Support > >>+Packet I/O interfaces operating in TAP mode now can feed packets to the ODP > >>+classifier the same as other pktio modes can do. > >>+ > >>+=== Performance Improvements > >>+ > >>+==== Thread-local cache optimizations > >>+The thread-local buffer cache has been reorganized and optimized for > >>burst-mode > >>+operation, yielding a measurable performance gain in almost all cases. > >>+ > >>+==== Burst-mode buffer allocation > >>+The scheduler and pktio components have been reworked to use burst-mode > >>+buffer allocation/deallocation, yielding a measurable performance gain in > >>+almost all cases. > >>+ > >>+==== Burst-mode queue operations > >>+ODP queues internally now attempt to use burst-mode enq/deq operations to > >>+accelerate performance where applicable. > >>+ > >>+==== Ring-based Scheduler Priority Queues > >>+The ODP scheduler has been enhanced to use ring-based priority queues, > >>resulting > >>+in significantly better scalability in many core environments. > >>+ > >>+==== GitHub Automation Support > >>+ODP now supports the Travis framework needed to trigger CI automation in > >>+conjunction with GitHub. This support is considered experimental for now. > >>+ > >>+=== Examples > >>+ > >>+==== New `l3fwd` Example > >>+A new example application is provided that illustrates use > >>+of ODP for simple Layer 3 forwarding across multiple interfaces. > >>+ > >>+==== "Hello World" Example Application > >>+A basic "hello world" ODP application has been added to the `example` > >>+directory to illustrate the basic setup and control flow needed by ODP > >>+applications. > >>+ > >>+=== Documentation > >>+ > >>+==== Pure API Documentation > >>+ODP now generates "pure" (implementation independent) doxygen > >>documentation in > >>+addition to the specific documentation for the odp-linux implementation. > >>The > >>+pure version is applicable to any ODP implementation as it simply describes > >>+the ODP API specification. Implementation-specific versions of this > >>+documentation describe both the APIs as well as specifics concerning > >>typedefs, > >>+enums, etc. This should help clarify what aspects of ODP are platform > >>+independent. > >>+ > >>+==== Clarify ODP Thread Definition > >>+The definition of an ODP thread in odp-linux has been clarified to specify > >>that > >>+for this implementation ODP threads are Linux pthreads or Linux processes. > >>+Currently threads as processes is considered experimental in odp-linux. > >>+ > >>+=== Bug Fixes > >>+Numerous refinements have been incorporated to make > >>+validation tests more robust in API coverage as well as correcting corner > >>+cases in the implementation of many ODP APIs. Notable fixes include: > >>+ > >>+==== https://bugs.linaro.org/show_bug.cgi?id=2316[Bug 2316] > >>+`ODP_TIMEOUT_INVALID` is now defined consistently with other pool elements > >>so > >>+the restriction on using Pool 0 as a timer pool is removed. > >>+ > >>+==== https://bugs.linaro.org/show_bug.cgi?id=2310[Bug 2310] > >>+The `odp_packet_copy()` API now correctly handles user areas between pools > >>that > >>+are configured with different sized per-packet user area definitions. > >>+ > >>+==== https://bugs.linaro.org/show_bug.cgi?id=2571[Bug 2571] > >>+Corrects the implementation of AES GCM decryption in the ODP crypto API. > >>+ > >>+=== Known Issues > >>+ > >>+==== https://bugs.linaro.org/show_bug.cgi?id=2309[Bug 2309] > >>+The Timer validation test fails sporadically in environments with high core > >>+counts. > >>+ > >> == OpenDataPlane (1.10.1.0) > >> > >> === New Features > >>-- > >>2.7.4 > >> > -- Anders Roxell anders.rox...@linaro.org M: +46 709 71 42 85 | IRC: roxell
