From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 6246F5B3C; Wed, 10 Apr 2019 11:43:13 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id t17so2058912wrw.13; Wed, 10 Apr 2019 02:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=FJyg9+ApkRyEF4dwqHuGUps+gtDAWAIbmQd9VlQuGho=; b=ETFku1QC5cSPHIAhFSkapFmgCIONN/hcYTXA6oXMlP90dRYYjP+RooXeG9kxwVwTsY UBEfWouZ9Sovr52MzxBEDqYV2rpw1CWHeiOIIHcMm1VMjfQvLXGbjE8+JrJ4gNXh84UT /9O4UsMxWCDjxOHjdy8/ySgqnWhjt6KFAOWUtySLy0W/ISAeg3wMUjfziD8Aeyi7emJi +BtCUYO8Nqc8e1Ct8Gsqxy+6Cyv6nlsRNQwlYaJSMYEf71sfsIHo/70yAKY2YTs9NgPv IUq88II8c7XM68Tt9bpPy0vmGItmwkbJFsT1F1iVhvZyGX7hibZW4YYefWwcK3nxt5mH YAow== X-Gm-Message-State: APjAAAXrl4+DOyCoLoHFAFnDjLi34xnnOuuqi9r2OJX1nl7XbDtY4+yt D4WkzikrMuwHeelYxwUu6+M= X-Google-Smtp-Source: APXvYqydPhZ/c5Z9G3b+FDmFHFM+MipwSdTrJ54SoMSnO93gmQ4YqylZ6bjfH9d+dDSyqLgKPyXLuQ== X-Received: by 2002:adf:cd83:: with SMTP id q3mr25212758wrj.228.1554889392875; Wed, 10 Apr 2019 02:43:12 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id z10sm1695126wmi.15.2019.04.10.02.43.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Apr 2019 02:43:11 -0700 (PDT) Message-ID: <5e8659411d5a11297ca2f158d98733b93debc56a.camel@debian.org> From: Luca Boccassi To: Honnappa Nagarahalli , Ray Kinsella , "dev@dpdk.org" , Kevin Traynor , "techboard@dpdk.org" Cc: nd Date: Wed, 10 Apr 2019 10:43:10 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] DPDK ABI/API Stability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 09:43:13 -0000 On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote: > > I guess the short story is that DPDK ABI hasn't really settled down > > as the > > project has matured. If you take a look at the =E2=80=9CBackward Compat= .=E2=80=9D > > column which measures ABI compatibility compared to the previous > > releases, you will see significant churn in the ABI over successive > > releases > > since v16.04. > >=20 > > Now compare DPDK to GStreamer as an example of a very mature > > project > > with a similar intent, a framework for building applications, and > > which > > enjoys a very stable API. > >=20 > > https://abi-laboratory.pro/index.php?view=3Dtimeline&l=3Dgstreamer > >=20 > >=20 > > The DPDK ABI churn has the following affects for users:- > >=20 > > 1. The churn obliges users of DPDK to commit to a constant re- > > integration > > and re-validation effort for new versions of DPDK. This effort from > > their > > perspective may not add value to their consuming project, > > particular if > > they are only updating to "stay current". >=20 > Even if the ABI did not change, any claim of support with newer > version needs re-validation. I think, re-integration is the only > extra effort. >>From first-hand experience: re-integration and re-validation are different in scope and resource requirements. Validation is usually done by the QA group, and usually doesn't cover just one library that makes up a part of a product. In other words, whether the DPDK version changes or not, a new version of a product will typically undergo full regression testing anyway. Integration is done by the development group. Any engineering-days that have to be dedicated to re-integrate a new version of DPDK are resources taken away from development of new features or bug fixing. Maintenance costs of OSS components are a sometimes overlooked but critical part of correctly scoping the opex of a project, and it's something that product/project managers do look at. > Why would anyone like to move to newer version just to stay current > if the newer version does not add any value to them? IMO, this is > doing work for no benefit. For many reasons. For example the argument I always use is that while new version Y might not be needed, new version Z might suddenly become required for the successful delivery of critical feature A, or to fix critical bug B. In my experience, jumping from version X to Y and then Y to Z is always cheaper and quicker and lower effort than jumping from X to Z, and the larger the jump, the more work it is. Another reason is that it's orders of magnitude cheaper to consume dependencies from the base distribution of choice when building a Linux product, rather than vendorizing. Doing that has of course drawbacks, including not being in control of the version of dependencies - so you don't have a choice, you need to keep up as the base distro moves on. --=20 Kind regards, Luca Boccassi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D9B49A0096 for ; Wed, 10 Apr 2019 11:43:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7841D5F17; Wed, 10 Apr 2019 11:43:14 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id 6246F5B3C; Wed, 10 Apr 2019 11:43:13 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id t17so2058912wrw.13; Wed, 10 Apr 2019 02:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=FJyg9+ApkRyEF4dwqHuGUps+gtDAWAIbmQd9VlQuGho=; b=ETFku1QC5cSPHIAhFSkapFmgCIONN/hcYTXA6oXMlP90dRYYjP+RooXeG9kxwVwTsY UBEfWouZ9Sovr52MzxBEDqYV2rpw1CWHeiOIIHcMm1VMjfQvLXGbjE8+JrJ4gNXh84UT /9O4UsMxWCDjxOHjdy8/ySgqnWhjt6KFAOWUtySLy0W/ISAeg3wMUjfziD8Aeyi7emJi +BtCUYO8Nqc8e1Ct8Gsqxy+6Cyv6nlsRNQwlYaJSMYEf71sfsIHo/70yAKY2YTs9NgPv IUq88II8c7XM68Tt9bpPy0vmGItmwkbJFsT1F1iVhvZyGX7hibZW4YYefWwcK3nxt5mH YAow== X-Gm-Message-State: APjAAAXrl4+DOyCoLoHFAFnDjLi34xnnOuuqi9r2OJX1nl7XbDtY4+yt D4WkzikrMuwHeelYxwUu6+M= X-Google-Smtp-Source: APXvYqydPhZ/c5Z9G3b+FDmFHFM+MipwSdTrJ54SoMSnO93gmQ4YqylZ6bjfH9d+dDSyqLgKPyXLuQ== X-Received: by 2002:adf:cd83:: with SMTP id q3mr25212758wrj.228.1554889392875; Wed, 10 Apr 2019 02:43:12 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id z10sm1695126wmi.15.2019.04.10.02.43.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Apr 2019 02:43:11 -0700 (PDT) Message-ID: <5e8659411d5a11297ca2f158d98733b93debc56a.camel@debian.org> From: Luca Boccassi To: Honnappa Nagarahalli , Ray Kinsella , "dev@dpdk.org" , Kevin Traynor , "techboard@dpdk.org" Cc: nd Date: Wed, 10 Apr 2019 10:43:10 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] DPDK ABI/API Stability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190410094310.ad189_TZugjFfy-lMeENJUKRQyQl1CC9q3aFcMKFQ2A@z> On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote: > > I guess the short story is that DPDK ABI hasn't really settled down > > as the > > project has matured. If you take a look at the =E2=80=9CBackward Compat= .=E2=80=9D > > column which measures ABI compatibility compared to the previous > > releases, you will see significant churn in the ABI over successive > > releases > > since v16.04. > >=20 > > Now compare DPDK to GStreamer as an example of a very mature > > project > > with a similar intent, a framework for building applications, and > > which > > enjoys a very stable API. > >=20 > > https://abi-laboratory.pro/index.php?view=3Dtimeline&l=3Dgstreamer > >=20 > >=20 > > The DPDK ABI churn has the following affects for users:- > >=20 > > 1. The churn obliges users of DPDK to commit to a constant re- > > integration > > and re-validation effort for new versions of DPDK. This effort from > > their > > perspective may not add value to their consuming project, > > particular if > > they are only updating to "stay current". >=20 > Even if the ABI did not change, any claim of support with newer > version needs re-validation. I think, re-integration is the only > extra effort. >From first-hand experience: re-integration and re-validation are different in scope and resource requirements. Validation is usually done by the QA group, and usually doesn't cover just one library that makes up a part of a product. In other words, whether the DPDK version changes or not, a new version of a product will typically undergo full regression testing anyway. Integration is done by the development group. Any engineering-days that have to be dedicated to re-integrate a new version of DPDK are resources taken away from development of new features or bug fixing. Maintenance costs of OSS components are a sometimes overlooked but critical part of correctly scoping the opex of a project, and it's something that product/project managers do look at. > Why would anyone like to move to newer version just to stay current > if the newer version does not add any value to them? IMO, this is > doing work for no benefit. For many reasons. For example the argument I always use is that while new version Y might not be needed, new version Z might suddenly become required for the successful delivery of critical feature A, or to fix critical bug B. In my experience, jumping from version X to Y and then Y to Z is always cheaper and quicker and lower effort than jumping from X to Z, and the larger the jump, the more work it is. Another reason is that it's orders of magnitude cheaper to consume dependencies from the base distribution of choice when building a Linux product, rather than vendorizing. Doing that has of course drawbacks, including not being in control of the version of dependencies - so you don't have a choice, you need to keep up as the base distro moves on. --=20 Kind regards, Luca Boccassi