From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 526855586 for ; Mon, 13 Jun 2016 12:21:52 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id n184so71633078wmn.1 for ; Mon, 13 Jun 2016 03:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=FhiV1x0GtXPLiCrM5g0/xwsAQzKwBkkOeCNozZ8aBPI=; b=lozZ0wNouVcV78x9+WpLHXIEYw9dcGlD9Yt4uPE8p81VpVS6Z3O5as22BNVOTpVFhh NBqk5r98x/CON2HaAXdQ5hLnoVsVugFemdZQh+TZC3x4MB9PZqDdKeSWzRKWvy5ydgMD ARGflUNCdL82lrBraQVqR4X7qZuXiF54VU/267mgvPGjzgSJVYjTFwENVDQE9kEuqhPC vms+3WL1BhLE9XJmXmqUTcM6V2e2xnd571iWDJsCeG2HlERSduae+7p3CwJWqq/Rj4GH yUKwBx8eHFyYto/FQVyosFznnrxx2vMqwHSi7iJthBRtqi2x+bt/ZG61mgg9BMwWeWyU //aA== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=FhiV1x0GtXPLiCrM5g0/xwsAQzKwBkkOeCNozZ8aBPI=; b=edDuU/416i9hNbYwsau9Y8LI7MZqeCB8+gL2qJl4CKBj7ABQdkZpdSPzPnexXScxIe PppIeGPnV8t0PocSo+UN6p91jmhGcwv+GjAcVN1a/J0YJgJvB6NiREJOdVX4xbv/7UZ2 cRGZUxm1PWyUhN0Pk+mLcJrOHcCaT/5Fh1cCWqW+YMOzLslx4mayjKHb8Rs8Sn4T17gk nZIiZAEuaHE/toP68YSGtdRofbyuCNkdeyMlGeFer+6BUEyvRzlQLf14x4Nx/rZYym0I dbAVkBTe01OBV/YfX6SqX6oIxsaptyQS9zoAqG7mkG8djTpymF3GS+ICxKaLn+TvyFeL kIFw== X-Gm-Message-State: ALyK8tIkp2wTlSyYv3iGzNGFi6Ty23p5aaM+vdGbzJZl1C0WMnU0dYvi3sKI/hRwqTas84Il X-Received: by 10.194.10.69 with SMTP id g5mr334774wjb.7.1465813312118; Mon, 13 Jun 2016 03:21:52 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id z14sm25437355wjw.6.2016.06.13.03.21.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2016 03:21:51 -0700 (PDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Panu Matilainen , Christian Ehrhardt Date: Mon, 13 Jun 2016 12:21:50 +0200 Message-ID: <2346375.5264sTWdP2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <575E8543.2080504@intel.com> References: <1465564749-1405-1-git-send-email-thomas.monjalon@6wind.com> <3213594.AWeSi4j5H8@xps13> <575E8543.2080504@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 3/6] mk: sort libraries when linking, move pmd libs to higher level 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: Mon, 13 Jun 2016 10:21:52 -0000 2016-06-13 11:04, Ferruh Yigit: > On 6/13/2016 10:29 AM, Thomas Monjalon wrote: > > 2016-06-10 19:32, Ferruh Yigit: > >> As stated in the comment: > >> Order is important: from higher level to lower level > >> > >> This is an attempt to make the layering order better respected. > >> > >> Limit scope of --whole-archive to pmd libraries > > > > Compared to the link order in the v2, you did two things: > > 1/ move PMDs to the first position > > 2/ restrict --whole-archive to PMDs only > > > > Having the PMDs first, helps the linker to get all the PMD dependencies > > in the static binary. Thus it seems we do not need --whole-archive > > for the PMD dependencies (ethdev, mbuf, etc). > > But, if an external PMD is loaded via dlopen, it is possible that it > > needs a symbol which was not used by the internal PMDs. So it will not > > be found in the statically linked binary. > > Let's take another example: if we disable the internal PMDs with their > > config options from the static build, and we decide to build them > > separately as DSOs. We won't be able to load them as plugins because > > they depend on symbols which won't be found in the static binary. > > So you want to keep all objects in final binary (used or unused) because > of the possibility that any plugin may use them. Yes > But what is the list to include here, whole dpdk?, -since we may not > know what API will plugin call. The list of the libraries candidates to be called from a driver can be discussed. The top layers like lpm or distributor should not be in this list I think. > What I am confused is --whole-archive only used when dpdk compiled as > static, if dpdk compiled as shared, each PMD should have proper > dependencies [1], and if external PMD compiled properly there shouldn't > be a problem. So do we have a case that dpdk compiled statically into > final binary but we still want to load some plugins dynamically? Yes a plugin can be loaded from a static binary. Breaking this feature would need a separate discussion and notices. > > To make it short, the PMDs must be considered as plugins. Therefore, we > > must not rely on their availability to link the required symbols in > > a static binary. > > To make sure the plugin loading will be always well achieved, we must > > link the static PMDs at the last position. > > I think this is not the issue of linking PMD's first or last, but > expanding --whole-archive to cover other libraries other than PMDs. Yes, linking PMD at the end is a way to force us to keep some libraries in --whole-archive. > > If you agree, I vote for the v2 of this patchset. > > If this is breaking something and best way to fix is not in external PMD > but in here, please feel free to go with v2. I don't see any other solution. But I'm sure we could discuss it more and/or improve it in the future.