From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by dpdk.org (Postfix) with ESMTP id 3ED5AAF85 for ; Tue, 15 Apr 2014 10:31:25 +0200 (CEST) Received: by mail-wi0-f177.google.com with SMTP id cc10so5256569wib.4 for ; Tue, 15 Apr 2014 01:31:25 -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=Dw6Pj+uAlql8cU8as7Xs+VfxMM8bDqy1X2Or13ivHQE=; b=kLjRi3nTNdqi/CgP5WOy1YFf+Iioa7GdHF5TD+1OEdpQW7v4zNXfDjtAgdjh5qL3qk 9lC0TBG6UxAqGIVMfpP37ltt0M7OaQMyJP2oUMmB1TTT1TPYmhVyewkBnE5lqOgfZl/a 8cjl7cPSI0gXPCkSSaiMtcTf6vGYkuZKHyb/6JDnqQM7svhlYRhujF//5xexRxvGGJzy 55pShCo4uv2Y2HeGKudRcBDVW4OuBw6Nm/1e72HTaOJLAvP5QuxAohf3TsHhtSMuiVTA Z9al+wjMRuCW2h/qXHCY3JN2PRO7e3r/82aJekvoEYXLtxR02Ls0UdAMnUOL0HYLguyp fSFw== X-Gm-Message-State: ALoCoQlTv/5gsvKcmJDOCizIxFpF42A52lqpmhWzLKDHQWiK8zNZ5kNK2iT+bHrpDaDY/wyH3xta X-Received: by 10.180.11.36 with SMTP id n4mr1445404wib.4.1397550685333; Tue, 15 Apr 2014 01:31:25 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id fs16sm28232767wic.18.2014.04.15.01.31.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Apr 2014 01:31:24 -0700 (PDT) From: Thomas Monjalon To: Neil Horman Date: Tue, 15 Apr 2014 10:31:25 +0200 Message-ID: <199653289.4Q8XNhu7Hx@xps13> Organization: 6WIND User-Agent: KMail/4.12.3 (Linux/3.13.7-1-ARCH; KDE/4.12.3; x86_64; ; ) In-Reply-To: <20140412110425.GB30887@hmsreliant.think-freely.org> References: <1397162846-28912-1-git-send-email-nhorman@tuxdriver.com> <20140412110425.GB30887@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/19] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 08:31:25 -0000 2014-04-12 07:04, Neil Horman: > On Thu, Apr 10, 2014 at 04:47:07PM -0400, Neil Horman wrote: > > 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 two new > > macros, PMD_INIT_NONPCI and PMD_INIT. These two macros use constructors > > to register their init routines at runtime, either prior to the execution > > of main() when linked statically, or when dlopen is called on a DSO at > > run time. The result is that PMD's can be loaded at run time without the > > application or eal library having to hold a reference to them. They work > > in a very simmilar fashion to the module_init routine in the linux > > kernel. > > > > 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. > > > > Regards > > Neil > > Self NAK on this, based on the conversation Thomas and I had about Oliviers > patches from a while back, I'm going to rebase and repost these soon. > Neil I'll be glad to get your fixes soon. So I could apply them for version 1.6.0r2 and release it. But I think you should post API changes (if any) in another series. Then we'll think if we want to push it in another branch for next major version. Thanks Neil -- Thomas