From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f179.google.com (mail-yb0-f179.google.com [209.85.213.179]) by dpdk.org (Postfix) with ESMTP id 04B732BAA for ; Fri, 24 Feb 2017 08:33:04 +0100 (CET) Received: by mail-yb0-f179.google.com with SMTP id a5so3504418ybb.2 for ; Thu, 23 Feb 2017 23:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bdLWgmgmVtU1x12joC4dI+wEcCVOukFxbuN5YdZ+Wk8=; b=PlwDPvKR2sscOIbkaACmB+VXYBKLcC5AZEw9A/FNjNVsvbu814PJUFy8AhFBRgSgI0 m8ICEmayngZF1Otdo6Krxh/YD6ajXHn3B6ql/M7KOgMSW2Y/R/k4zWOCU4H1T1Xs2T6o nNPojK3aZpRoheZZS4dmqMHXiNwbZAvAfac4EnZMwg0obdpa1Lb7Gaifp89TxFQQQs9O qrdPZtWSkmm09MlQmRNnm3vosKzEW+HXx5gwJrSO987LW0QfvOXcsq7LUMhWToKj5D4G W4oD+PCczgRf+rltQDBJGvD4PYn6fVpdwAxal+TxiEYlJ+tpqsFpH2wWr2cwYtdRwJ4f IFdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bdLWgmgmVtU1x12joC4dI+wEcCVOukFxbuN5YdZ+Wk8=; b=qFhCUcayZltNNxbH9TgWPe3VAuxwpEiJk+2Zvay0imsftzkT3XlUjehubm5SdU9xpk P7RfhzzU9zyTP4zZzVPExeDTuusf6L6E7lobt7IkX/l/Kn2ISx/Z4d1S3Aj83CKxT2ZT ZyMfx8uY/T7YOKauqKnEccWDEYYL+n+9nCpAxDT+NaXe8QtdL/rWjoyb4Hc0abPfySFm r5v/Xh8DQvFp8LLF9PkLjmbsE405XxSuL+BPQdms25eae2RzN8ZdClrgtHnSc9vCQ5Cn yC5PxftA50yanyQyx/gkdzJzJUyWPH69exqRvp4tf64tq8jnqfkATVn5axcPoKTIP4t2 cQSA== X-Gm-Message-State: AMke39mGmQLxyhzW9A0gtX7I76GJjkXn19roC3LoA/BzwNKYCjALokzAR/+bxxWOIfm64MdGNZ+k785QAu4r/dlx X-Received: by 10.37.160.68 with SMTP id x62mr789099ybh.74.1487921584038; Thu, 23 Feb 2017 23:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.59.11 with HTTP; Thu, 23 Feb 2017 23:32:33 -0800 (PST) In-Reply-To: <6d7ee27e-8d96-7741-3cc0-415e5486ad48@intel.com> References: <6d7ee27e-8d96-7741-3cc0-415e5486ad48@intel.com> From: Christian Ehrhardt Date: Fri, 24 Feb 2017 08:32:33 +0100 Message-ID: To: Ferruh Yigit Cc: Jan Blunck , dev , "cjcollier@linuxfoundation.org" , ricardo.salveti@linaro.org, Luca Boccassi Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Further fun with ABI tracking 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: Fri, 24 Feb 2017 07:33:05 -0000 On Thu, Feb 23, 2017 at 7:48 PM, Ferruh Yigit wrote: > Can you please describe this option more? > Of course, I happy about any engagement/discussion to have on that. Much better than silently staying in queue. > Does is mean for each DPDK release, distro will release all libraries? > First of all it is opt-in. If nobody does change the default setting (="") to anything nothing happens. A distribution _CAN_ use the feature to reliably avoid collisions between DPDK releases and allow concurrent installations more easily. > For 16.07: > acl.2, eal.2, ethdev.4, pdump.1 > > For 16.11: > acl.2, eal.3, ethdev.5, pdump.1 > That example is what we did so far, trying to follow the DPDK ABI versioning. But that caused the issue I described with (new)pdump.1->eal.3 and the base app->eal2 Will dpdk package have following packages: > acl.16.07.2, eal.16.07.2, ethdev.16.07.4, pdump.16.07.1 > acl.16.11.2, eal.16.11.3, ethdev.16.11.5, pdump.16.11.1 > I thought on that, but Jan correctly brought up that if we do override we should as well trivialize and override fully - ignoring the per lib LIBABIVER. So it will not be eal.16.11.3 but instead just eal.16.11 (no subversion, as there is no need). If that is wanted that can easily be done, please let me know if I should run a v2 with that. And for initial OVS usecase, will it be: > > OVS > +---> eal.16.07.2 > +---> pdump.16.11.1 > +---> eal.16.11.3 > > Not quite, the usecase would look like that: The current DPDK generates LIBABIVER versions: eal.3, pdump.1, ... OVS +---> eal.3 +---> pdump.1 +---> eal.3 Note: Packages are initially carried forward from the former Distrobution release, so the next release would start as the former has ended: OVS +---> eal.3 +---> pdump.1 +---> eal.3 Then the new DPDK would come in and using this feature would then generate all as major version: eal.17.02, pdump.17.02, ... But since OVS was not recompiled yet AND there is no collision OVS would still look like: OVS +---> eal.3 +---> pdump.1 +---> eal.3 Then we can recompile OVS and it will become OVS +---> eal.17.02 +---> pdump.17.02 +---> eal.17.02 Into the future with more apps depending on DPDK there can be many scenarios: 1. all are fine rebuilding, there will be no dependency left to the older dpdk and it will be autoremoved after all upgrades 2. some packages are slow to adapt, but that is fine we can still provide the old dependencies at the same time if needed 3. the time in between #2 and #1 is not wreaking havok as the cross-dependency issue is no more > Assuming above understanding is correct J : > > - If same version of the library will be delivered for each DPDK > release, what is the benefit of having fine grained libraries really? > The benefit of the fine grained versioning is for other types of distributing DPDK. Recognizing an ABI bump for lib-consuming developers, bundling it directly with your app, ... > - Above OVS usage still does not look right, I don't believe this is the > intention when library level dependency resolving introduced. > > Overall I am for single library, but I can see the benefit of having > multiple small libraries, that is why I vote for option 4 in your > initial mail. > Single library would solve it as well, but as mentioned and you all remember there were people with reasons for it that I could not challenge being too far out of the application scenarios they had in mind. And I agree this can cause problem if not automated, but we already know > the library dependencies, I think a script can be developed to warn a > least, and they can be updated manually. > > And isn't the purpose of increasing LIBABIVER to notify application that > library is modified and can't be used with that app anymore. > For DPDK, even if the library is not changed, if another library that it > depends modified, this may mean the behavior of the library may be > changed, so it makes sense to me if library notifies the user for this > case, by increasing its version. > > Yes this makes effect of increasing a core library version big, but I > believe this is also true, increasing a core library version almost > means increasing dpdk version. > Interesting - thanks for sharing your opinion here - I rethought that for a while now. While this could work I consider it inferior to the approach I submitted in the patch yesterday [1] for the following reasons: - If we bump infecting (looking at the recent history) we most likely end up bumping all libraries at least every other release. Now there isn't much different in bumping all of them +1 or just using a single increasing version. Except you could miss a few bumps or track it wrong. - The new Feature is opt-in, allowing those who want to do that major bump; But at the same time allowing those who won't to keep on tracking each lib individually and build/deliver it that way. - I learned (often the hard way) that to be different often causes problems that are hard to foresee. The infecting ABI would be "DPDK is different" again, while the major override is somewhat established. For now I'd suggest taking the opt-in feature as suggested in [1] as a means for those who need it (like us and maybe more downstreams over time). If DPDK is evolving to become more stable and develops a feature like the #4 "infecting-abi-bump + tracking" it can still be picked us later and by anybody else who wants needs it. It will then "just" be dropping a config option we set before to get back. TL;DR: I think DPDK is not stable enough to make option #4 worth implementing for now to make a difference worth (but would cause lot of work and error potential). But since my code [1] implementing approach #1 and a later approach #4 in the future are not mutually exclusive I'd ask to go for #1 now and #4 later if one needs and implements it. [1]: http://dpdk.org/ml/archives/dev/2017-February/058121.html -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd