From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id 02DE7C85C for ; Fri, 19 Jun 2015 19:03:24 +0200 (CEST) Received: by wicnd19 with SMTP id nd19so24761677wic.1 for ; Fri, 19 Jun 2015 10:03:23 -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=f+/sm7Bk2o1TL/2nk79iU0folunMlX6J+rKUCzzYI/I=; b=IYg6r02SKVFvVhOBmIVUUbKHdUEk+gxS2ot7I8Zy5Omup/L6+s4QLHxastBpB/zxNC 1rvMazVWpmCsd3J0FL5NKS6ohT7kwNPBjWKddZ90D5CzYP2/umxsQ4HMWx7AalCmSoyB /tQ1Vh2xFIWu58hRLU9M7OCokT2+0+06KcGCnvTDEW/fphuYPukliegWlC6dtYm3VpO5 KzMT2n7z6qGXfvnu3nTgl/WsXepyR/6sFT8SOVZXXX3n0LUy9+9+e9/UlUQkWhBqOz87 oqR+LkOTYXmKSmgCVT7M2nKiDPG+aZ3Cx0Igjy2kFWssNlNLjyvbN6XcOUE4zaI2suHL mIag== X-Gm-Message-State: ALoCoQletHLZFIlazkZnClsTNTC/fVuOO3jPKWw5iFveWzLfDdo2rogUEjvECGQ1wOHASEPrL4mC X-Received: by 10.194.63.16 with SMTP id c16mr27611422wjs.105.1434733403803; Fri, 19 Jun 2015 10:03:23 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id pg1sm17881863wjb.39.2015.06.19.10.03.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 10:03:22 -0700 (PDT) From: Thomas Monjalon To: Thomas F Herbert Date: Fri, 19 Jun 2015 19:02:20 +0200 Message-ID: <1689307.QXWV6y3s1T@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <55843FBD.1050303@redhat.com> References: <9092314.MoyqUJ5VU2@xps13> <1784476.c2eg9hZKIA@xps13> <55843FBD.1050303@redhat.com> 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 17:03:24 -0000 2015-06-19 12:13, Thomas F Herbert: > > On 6/19/15 9:16 AM, Thomas Monjalon wrote: > > 2015-06-19 09:02, Neil Horman: > >> On Fri, Jun 19, 2015 at 02:32:33PM +0200, Thomas Monjalon wrote: > >>> 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. > >> > >> Hm, ok, thats a bit more reasonable, but it still seems shaky to me. > >> Implementing an ABI preview option like this implies the notion that, after a > >> release, you have to remove all the ifdefs that you inserted to create the new > >> ABI. That seems like an easy task, but it becomes a pain when the ABI delta is > >> large, and is predicated on the centralization of work effort (that is to say > >> you need to identify someone to submit the 'remove the NEXT_ABI config ifdefs > >> from the build' patch every release. > > > > It won't be so huge if we reserve the NEXT_ABI solution to changes which cannot > > have easy backward compatibility with the compat macros you introduced. > > I feel I can do the job of removing the ifdefs NEXT_ABI after each release. > > At the same time, the deprecated API, using the compat macros, will be removed. > > > >> What might be better would be a dpdk-next branch (or even a dpdk-next tree, of > >> the sort that Thomas Herbert proposed a few weeks ago). > > > > This tree was created after Thomas' request: > > http://dpdk.org/browse/next/dpdk-next/ > > Thomas, I am sorry if I went quiet for awhile but I was on personal > travel with inconsistent access so I almost missed most of this > discussion about ABI changes. > > My understanding of the purpose of the dpdk-next tree is to validate > patches by applying and compiling against a "pull" from the main dpdk > tree. I think a good way to handle ABI change while effectively using > the dpdk-next might be to do as follows: > > Create a specific branch for the new ABI such as 2.X in the main dpdk > tree. Once that 2.X branch is created, dpdk-next would mirror the 2.X > branch along with master. > > Since, dpdk-next would also have the 2.X branch that is in the main dpdk > tree, submitted patches could be applied to either the main branch or > the new-ABI 2.X branch. Providing that patch submitters make it clear > whether a submitted patch is for the new ABI or the old ABI, dpdk-next > could continue to validate the patches for either the main branch or the > new ABI 2.X branch. What is the benefit of a new-ABI branch in the -next tree? The goal of this discussion is to find a consensus on ABI policy to smoothly integrate new features without forcing users of shared libraries to re-build their application when upgrading DPDK, and let them do the transition before the next upgrade.