From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 672D58DB4 for ; Thu, 3 Dec 2015 02:31:36 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2015 17:31:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,375,1444719600"; d="scan'208";a="611596117" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by FMSMGA003.fm.intel.com with ESMTP; 02 Dec 2015 17:31:34 -0800 Received: from sivlogin002.ir.intel.com (sivlogin002.ir.intel.com [10.237.217.37]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id tB31VY2Y017657; Thu, 3 Dec 2015 01:31:34 GMT Received: from sivlogin002.ir.intel.com (localhost [127.0.0.1]) by sivlogin002.ir.intel.com with ESMTP id tB31VYf1021470; Thu, 3 Dec 2015 01:31:34 GMT Received: (from fyigit@localhost) by sivlogin002.ir.intel.com with œ id tB31VXn9021466; Thu, 3 Dec 2015 01:31:33 GMT X-Authentication-Warning: sivlogin002.ir.intel.com: fyigit set sender to ferruh.yigit@intel.com using -f Date: Thu, 3 Dec 2015 01:31:33 +0000 From: Ferruh Yigit To: Neil Horman Message-ID: <20151203013133.GA20974@sivlogin002.ir.intel.com> Mail-Followup-To: Neil Horman , Robie Basak , dev@dpdk.org References: <079fa1cfc3550c8147ea8b137fa1bc0f34d051dc.1448375477.git.pmatilai@redhat.com> <20151201123736.GJ28475@mal.justgohome.co.uk> <20151202114419.GB22216@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151202114419.GB22216@hmsreliant.think-freely.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script 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: Thu, 03 Dec 2015 01:31:37 -0000 On Wed, Dec 02, 2015 at 06:44:19AM -0500, Neil Horman wrote: > On Tue, Dec 01, 2015 at 12:37:37PM +0000, Robie Basak wrote: > > Re-sending this unsigned since the ML rejected my signed email. > > > > -1 from Ubuntu without further discussion since it will break us. Please > > don't commit this patch yet. > > > > I don't understand why we must have the complexity of so many shared > > libraries. From a distribution packaging perspective, all I see is that > > this multiplies potential work by twenty times and makes it awkward to > > work with without special tooling (which then needs maintaining). > > > Theres nothing "complex" about the simple fact that a project builds lots of > libraries. Its extreemely common. Any graphic window manager has exactly the > same situation, as do any number of tools that have multiple hardware backends > impelmented in user space (v4l, sane, iptables, to name just a few). > > > Before I go into details, it would be nice if someone could please > > explain why DPDK has to be "special" in needing to do this? I don't > Its not special, see above. Not saying the build environment cant be improved, > but the fact that there are multiple libraries is pretty straightforward. > > > understand why DPDK must be different to every other userspace library > > out there. If DPDK has a good need to be different then that's fair > > enough. But I feel that if DPDK is deviating from the norm then we need > > to frame the discussion from the perspective of "why DPDK must be > > different", rather than having me trying to explain why the norm is the > > right way to do it. > > > > On Tue, Nov 24, 2015 at 04:31:17PM +0200, Panu Matilainen wrote: > > > That's how Fedora and RHEL are shipping it already and nobody has so much > > > as noticed anything strange, much less complained about it. 20 libraries > > > is but a drop in the ocean on a average distro. > > > > No, it is 20 times the work from the perspective of DPDK package > > maintenance. Let me explain why. > > > > In Debian and Ubuntu, we manage a library transition (an ABI bump in a > > library together with all dependencies moving to use the new ABI) by > > concurrently packaging both the old and new libraries at once. This > > works well with the norm for libraries. We ship one binary package per > > soname, with the major version as part of the package name. This allows > > a system to have two (or more) ABIs installed simultaneously. For a > > library transition, we just package the new version and then that can > > land and work concurrently as we then individually update every > > dependent (library-consuming) package. > So thats, a distribution choice, not an upstream problem. And it seems like a > problem you should have already solved (note the examples above). If you feel > like you need to package multiple ABI versions in the same library, you can, > just update the LIBABIVER of all the libraries, instead of the ones that truly > change, so that each library is guaranteed a newer so version, to make the > library file name unique. Yes you have to make a small change from upstream, > but thats part of the work that distribution maintainers do. > > > > This works because of conventions around sonames, which DPDK breaks > > unless we treat it as twenty different libraries which changes our work > > from easy to painful. > > > > Usually a library transition is managed by hand by the package > > maintainer. It's not taxing because it's straightforward and well > > understood. Update and upload the new ABI source package, then find all > > reverse dependencies and sort them out, recursively. But if the > > maintainer must do it twenty times, then it becomes taxing and prone to > > error. And if the reverse dependency tree differs depending on the split > > library used by library consumers, then it gets far more complex to > > follow. > > > > Admittedly we could tool around this to make it easier, but that's extra > > work (both initially and in maintenance) and prone to error (because > > we'd only be doing it for DPDK). > > > You must already have a solution to this, I can't imagine you package all the > libraries for kde or gnome (or even pam) separately) > > > Packaging a library is usually virtually a no-op in Debian and Ubuntu > > nowadays. Our tooling does it all for us. But packaging DPDK is far from > > this currently because of all this added complexity. From my perspective > > this is unnecessary and makes no sense. We could do all kinds of things > > to work around it (that's what packaging is about) but then we'd have to > > maintain that specialness and I don't see why it must be awkward like > > this instead of just doing it the same way as every other library. > > > > > The combined library as it is simply is no longer a viable option. > > > Besides just being broken (witness the strange hacks people are coming > > > up with to work around issues in it) its ugly because it basically gives > > > the middle finger to all the effort going into version compatibility, > > > and its also big. Few projects will use every library in DPDK, but with > > > the combined library they're forced to lug the 800 pound gorilla along > > > needlessly. > > > > It's broken because it's broken upstream, and that's what we should fix. > > Why is it not viable? How does it give the middle finger to effort going > > into version compatibility? > Because each individual library has a version script that gets applied during > link to version symbols properly. Those scripts dont get applied when building > the combined library. > > > > Doing it the right way like every other > > userspace library is what *gives us* version compatibility because then > > distributions can straightforwardly install multiple ABI versions at > > once. > Again, Not at all uncommon. You're packaging methodology is the issue here, > not the fact that there are multiple libraries. > > > Finally, I fail to see any "lug the 800 pound gorilla along" saving. We > > (Ubuntu and Fedora) are both shipping all the libraries in one package, > > whether split or combined, so they are all being lugged onto disk > > anyway. Whether split or combined, there is no saving there. And memory > > is hardly saved either because the kernel will just page in and out what > > is needed in both cases. So how does this proposed change give us any > > saving at all? > > > Not true, initalization constructors for PMD's at the very least mean that every > pmd will get paged in weather you want it or not using the combined library. > Individual libraries let you dynamically load them (via dlopen). I think the > same is true of several other facets of dpdk. > > Neil > I just sent a patch that fixes versioning in combined library, can you please check it: http://dpdk.org/dev/patchwork/patch/9259/ Thanks, ferruh