From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
 [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id E9C4C312
 for <dev@dpdk.org>; Tue, 20 May 2014 14:45:02 +0200 (CEST)
Received: by mail-wi0-f179.google.com with SMTP id bs8so858817wib.6
 for <dev@dpdk.org>; Tue, 20 May 2014 05:45:12 -0700 (PDT)
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:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=1ML+CTnstmJD2IPILIV2QDMX3642gE/oZIIlrydiRIc=;
 b=V+tHm7E+Ep/yh+9WdsMtpHuY95WVobnePPPagNCoDEq5uSjTXLk2fWdhl3TkwwG1fv
 cW8usOL6k0tur2hEfDZAipTT8VWoHre9GVYoGFbkEqx7ihRsWzs2IZnGlBVLpeVDQGl+
 FCORxbXpaD/y2KZHybV0ZAAYGrL6Rx2fOtHYIBQQOj1a4EZaNKKp8qGf3r5FHD9oYUec
 vpr8CkLVgSCPpojmQCnKdgdSnDJWveIexNnttL9hO3i3FzoCLcIm5xT1Ipx/IbSltezb
 tI1fJ5b0Cg2cXjrDT4uHR3rLV0rmOfMU/j585zBq+/NuD/0UhpOsuZCgLQay6yMoxa3k
 BQZg==
X-Gm-Message-State: ALoCoQlIaoDQiQXpsu3e6pls6e6Bx6CcmoFHgokBZh2aB17xIWWlDJV4WAMKYRKOjTphAfPSdkD/
X-Received: by 10.180.99.40 with SMTP id en8mr4000512wib.24.1400589912013;
 Tue, 20 May 2014 05:45:12 -0700 (PDT)
Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237])
 by mx.google.com with ESMTPSA id m1sm4520433wib.20.2014.05.20.05.45.10
 for <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 20 May 2014 05:45:11 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 20 May 2014 14:45:09 +0200
Message-ID: <1625721.M2ZgnCqEoJ@xps13>
Organization: 6WIND
User-Agent: KMail/4.13 (Linux/3.14.4-1-ARCH; KDE/4.13.0; x86_64; ; )
In-Reply-To: <1398092379-7679-1-git-send-email-nhorman@tuxdriver.com>
References: <1397585169-14537-1-git-send-email-nhorman@tuxdriver.com>
 <1398092379-7679-1-git-send-email-nhorman@tuxdriver.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v5 00/14] dpdk: Separate compile time linkage
	between eal lib and pmd's
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: Tue, 20 May 2014 12:45:03 -0000

2014-04-21 10:59, Neil Horman:
> Disconnect compile time linkage between eal library / applications and pmd's
> 
> I noticed that, while tinkering with dpdk, building for shared libraries
> still resulted in all the test applications linking to all the built pmd's,
> despite not actually needing them all.  We are able to tell an application
> at run time (via the -d/--blacklist/--whitelist/--vdev options) which pmd's
> we want to use, and so have no need to link them at all. The only reason
> they get pulled in is because rte_eal_non_pci_init_etherdev and
> rte_pmd_init_all contain static lists to the individual pmd init functions.
> The result is that, even when building as DSO's, we have to load all the
> pmd libraries, which is space inefficient and defeating of some of the
> purpose of shared objects.
> 
> To correct this, I developed this patch series, which introduces a new
> macro, PMD_REGISTER_DRIVER, which wraps up Oliviers work using constructors
> on the virtual device pmds, then expands on it to include the physical
> device pmds, allowing us to break linkages between dpdk applications and
> pmd's almost entirely (save for the ring and xenvirt drivers, which have
> additional api's outside of the standard dpdk code that we need to further
> fix).  This also allows us to completely remove the rte_pmd_init_all
> routine, hiding its function internally to the rte_eal_init path.
> 
> I've tested this feature using the igb and pcap pmd's, both statically and
> dynamically linked with the test and testpmd sample applications, and it
> seems to work well.
> 
> Note, I encountered  a few bugs along the way, which I fixed and noted in
> the series.

Thanks for this nice cleanup.

Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Applied for version 1.7.0.

-- 
Thomas