From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=qYunP7tu31nEgWX8Z2ZyUw+i+u409G/a0/OiI2bJv+Q=; b=XREP+4WQLCDIH2ScrPEqcQM6TP5EW6I0HVTkEVtUkbX4Dioc4bEJELIktjOHqQQx7t WGJIj95m9j60tMHOnBGwDr8RytlMgocW7V4Z7r94794iax/GRzF/sa83gEdu/YpuzPIt w9oVCukzImNf8P9VTS4Br+3g/Ayx6v722PuQ1OfUPjJjh0xGSTE2XXC0ZErMSoKOlV3O vG50HhH+W9Oks7LImHbTLsHgSIdHbXBloyKbfsMNBNRiI8tPVXNbGsGb9NNwD+EeDDJ6 S+ys5FwUcvhc/vYmQSwqzkX9tiO4V1vER2j0c0UkE5pgc8/dlMitf5fwr1Q+xq/xQgGB Uc0g== X-Gm-Message-State: ALoCoQmbNlD8MCdWUVi/f2pQbEj5kEnEl1SGUtf73cOjYYsVAidHTybUNTYNEagNFTm18WXyQ8+o X-Received: by 10.180.188.8 with SMTP id fw8mr6153111wic.65.1434717217241; Fri, 19 Jun 2015 05:33:37 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id v3sm3537781wiz.14.2015.06.19.05.33.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 05:33:35 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Fri, 19 Jun 2015 14:32:33 +0200 Message-ID: <2237584.tmRa3ku4eh@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150619102654.GA26678@hmsreliant.think-freely.org> References: <9092314.MoyqUJ5VU2@xps13> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D6D24C@IRSMSX102.ger.corp.intel.com> <20150619102654.GA26678@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 12:33:38 -0000 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.