From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sergio.gonzalez.monroy@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 5C8F55424
 for <dev@dpdk.org>; Thu, 22 Jan 2015 12:01:37 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by fmsmga102.fm.intel.com with ESMTP; 22 Jan 2015 03:01:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.09,448,1418112000"; d="scan'208";a="515938832"
Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157])
 by orsmga003.jf.intel.com with ESMTP; 22 Jan 2015 02:54:50 -0800
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.64]) by
 IRSMSX103.ger.corp.intel.com ([169.254.3.242]) with mapi id 14.03.0195.001;
 Thu, 22 Jan 2015 11:01:33 +0000
From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>, Neil Horman
 <nhorman@tuxdriver.com>
Thread-Topic: [dpdk-dev] [PATCH RFC 00/13] Update build system
Thread-Index: AQHQLoW0TkjRJqHabk2BE0EuYo1gOJy8sx2AgAADTmCAD0Do0IAACt+AgAAEo2A=
Date: Thu, 22 Jan 2015 11:01:31 +0000
Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004F412E9@IRSMSX108.ger.corp.intel.com>
References: <1421080446-19249-1-git-send-email-sergio.gonzalez.monroy@intel.com>
 <91383E96CE459D47BCE92EFBF5CE73B004F26FD1@IRSMSX108.ger.corp.intel.com>
 <91383E96CE459D47BCE92EFBF5CE73B004F412AF@IRSMSX108.ger.corp.intel.com>
 <2045513.NOD9qnQLhk@xps13>
In-Reply-To: <2045513.NOD9qnQLhk@xps13>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [163.33.239.182]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jan 2015 11:01:37 -0000

> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, January 22, 2015 10:39 AM
> To: Gonzalez Monroy, Sergio
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
>=20
> 2015-01-22 10:03, Gonzalez Monroy, Sergio:
> > > From: Gonzalez Monroy, Sergio
> > > Sent: Monday, January 12, 2015 5:22 PM
> > > To: Thomas Monjalon
> > > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
> > >
> > > Hi Thomas,
> > >
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > Sent: Monday, January 12, 2015 4:52 PM
> > > >
> > > > Hi Sergio,
> > > >
> > > > 2015-01-12 16:33, Sergio Gonzalez Monroy:
> > > > > This patch series updates the DPDK build system.
> > > >
> > > > Thanks for proposing such rework.
> > > > We need discussions on that topic. So I ask some questions below.
> > > >
> > > > > Following are the goals it tries to accomplish:
> > > > >  - Create a library containing core DPDK libraries (librte_eal,
> > > > >    librte_malloc, librte_mempool, librte_mbuf and librte_ring).
> > > > >    The idea of core libraries is to group those libraries that ar=
e
> > > > >    always required for any DPDK application.
> > > >
> > > > How is it better? Is it only to reduce dependencies lines?
> > > >
> > > In my opinion I think that there are a set of libraries that are
> > > always required and therefore should be grouped as a single one.
> > > Basically all apps and other DPDK libs would have dependencies to
> > > these core libraries.
> > >
> > > Aside from that, I don't think there is any difference. Note that
> > > this affects shared libraries, with no difference for apps linked aga=
inst
> static libs.
> > >
> > > > >  - Remove config option to build a combined library.
> > > >
> > > > Why removing combined library? Is there people finding it helpful?
> > > >
> > > I don't think it makes sense from a shared library point of view,
> > > maybe it does for static?
> > > For example, in the case of shared libraries I think we want to try
> > > to avoid the case where we have an app linked against
> > > librte_dpdk.so, but such library may contain different libraries
> > > depending on the options that were enabled when the lib was built.
> > >
> > > The core libraries would be that set of libraries that are always
> > > required for an app, and its content would be fixed regardless of
> > > the option libraries (like acl, hash, distributor, etc.) We could
> > > add more libraries as core if we think it is a better solution, but
> > > the goal should be that librte_core.so contains the same libraries/AP=
I
> regardless of the system/arch.
> > >
> > > > >  - For shared libraries, explicitly link against dependant
> > > > >    libraries (adding entries to DT_NEEDED).
> > > >
> > > > OK, good.
> > > >
> > > > >  - Update app linking flags against static/shared DPDK libs.
> > > > >
> > > > > Note that this patch turns up being quite big because of moving
> > > > > lib directories to a new subdirectory.
> > > > > I have ommited the actual diff from the patch doing the move of
> > > > > librte_eal as it is quite big (6MB). Probably a different
> > > > > approach is
> > > > preferred.
> > > >
> > > > Why do you think moving directories is needed?
> > > >
> > > Actually I am not sure is the best way to do this :) There is no
> > > need to move them, as the same result could be achieved without
> > > moving directories, but I thought that it would be easier for anyone =
to
> see which libraries are 'core'
> > > and which are not.
> > >
> > > Not moving those directories would definitely simplify this patch ser=
ies.
> > >
> > > > Thanks
> > > > --
> > > > Thomas
> > >
> > > Thanks,
> > > Sergio
> >
> > Hi Thomas,
> >
> > Any other comments/suggestions ?
> > My main concern would be the patch needed to move librte_eal (around
> 6MB).
> >
> > Thoughts?
>=20
> I think you shouldn't move the libs.
> Maybe we can link the core libs into one (not sure of the interest) but I=
 think
> we shouldn't move them in a core/ subdir.
>=20
> On another side, I'd like to see KNI moving out of EAL.
>=20
> --
> Thomas

I think moving KNI out of EAL belongs to a different patch.

We can still link librte_core without moving the directories into core/

I'll work on it.

Thanks,
Sergio