From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [dpdk-announce] important design choices - statistics - ABI Date: Fri, 19 Jun 2015 14:32:33 +0200 Message-ID: <2237584.tmRa3ku4eh@xps13> References: <9092314.MoyqUJ5VU2@xps13> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D6D24C@IRSMSX102.ger.corp.intel.com> <20150619102654.GA26678@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: Neil Horman Return-path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id 5DDFAC73C for ; Fri, 19 Jun 2015 14:33:38 +0200 (CEST) Received: by wicnd19 with SMTP id nd19so17744316wic.1 for ; Fri, 19 Jun 2015 05:33:37 -0700 (PDT) In-Reply-To: <20150619102654.GA26678@hmsreliant.think-freely.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-06-19 06:26, Neil Horman: > On Thu, Jun 18, 2015 at 04:55:45PM +0000, O'Driscoll, Tim wrote: > > For the 2.1 release, I think we should agree to make patches that change > > the ABI controllable via a compile-time option. I like Olivier's proposal > > on using a single option (CONFIG_RTE_NEXT_ABI) to control all of these > > changes instead of a separate option per patch set (see > > http://dpdk.org/ml/archives/dev/2015-June/019147.html), so I think we > > should rework the affected patch sets to use that approach for 2.1. > > This is a bad idea. Making ABI dependent on compile time options isn't a > maintainable solution. It breaks the notion of how LIBABIVER is supposed to > work (that is to say you make it impossible to really tell what ABI version you > are building). The idea was to make LIBABIVER increment dependent of CONFIG_RTE_NEXT_ABI. So one ABI version number refers always to the same ABI. > If you have two compile time options that modify the ABI, you > have to burn through 4 possible LIBABIVER version values to accomodate all > possible combinations, and then you need to remember that when you make them > statically applicable. The idea is to have only 1 compile-time option: CONFIG_RTE_NEXT_ABI. Your intent when introducing ABI policy was to allow smooth porting of applications from a DPDK version to another. Right? The adopted solution was to provide backward compatibility during 1 release. But there are cases where it's not possible. So the policy was to notice the future change and wait one release cycle to break the ABI (failing compatibility goals). The compile-time option may provide an alternative DPDK packaging when the ABI backward compatibility cannot be provided (case of mbuf changes). In such case, it's still possible to upgrade DPDK by providing 2 versions of DPDK libs. So the existing apps continue to link with the previous ABI and have the possibility of migrating to the new one. Another advantage of this approach is that we don't have to wait 1 release to integrate the changes. The last advantage is to benefit early of these changes with static libraries.