From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 30CA55A84 for ; Mon, 12 Jan 2015 16:17:24 +0100 (CET) Received: by mail-wg0-f52.google.com with SMTP id x12so19816403wgg.11 for ; Mon, 12 Jan 2015 07:17:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KcXCrRBz7rjGWWbrUpUcz1KaGf9lnMgqxzK+xXOgUZY=; b=AckG2OAy5wgHeJl4Gx2BA+Go4fQNtVOoIgGI5QNGoHHcvXvUOJY+aZ/LFoEgi+bORr 9qsFYcNO7nr3qJtjvSJExuGrenLrDZ9e5M+as0MprZRNy6Yqw2twrj+YjyBfqEC/QOvc H4aHgAF42X0OJp9JI/hbjzURzygXfk57mrwvFE3SYfSBAYnfj9ERiWVo6ZGgebpsp6Zz H2EHe7l/b3ly+PsLakBi4dNOxhKZKYvnDYCx5KH3d2MG0cBASF5ohDXN46MjfXWomGlH bK8+U6MJTYwP4XImIZFYRfzFhiCLDwBinjrtnHy5exA/t+VbUXvZn9/w3qR/OCMQRZ4f ++Kg== X-Gm-Message-State: ALoCoQnDe/Z/IQLwx5N0GaWsqieD9grU2sLdz/pHiIzD09AXzICQ8MvkT1qfzqR5M59/Uf/mAWkk X-Received: by 10.180.91.37 with SMTP id cb5mr31372553wib.1.1421075844018; Mon, 12 Jan 2015 07:17:24 -0800 (PST) Received: from [10.0.0.165] (system.cloudius-systems.com. [84.94.198.183]) by mx.google.com with ESMTPSA id c10sm22008078wjy.4.2015.01.12.07.17.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 07:17:23 -0800 (PST) Message-ID: <54B3E581.5010002@cloudius-systems.com> Date: Mon, 12 Jan 2015 17:17:21 +0200 From: Vlad Zolotarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Neil Horman , Bruce Richardson References: <54B2AE86.3050203@cloudius-systems.com> <20150112113025.GC13136@bricha3-MOBL3> <20150112145026.GB23467@hmsreliant.think-freely.org> In-Reply-To: <20150112145026.GB23467@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , Shlomi Livne Subject: Re: [dpdk-dev] What is the best way to distribute a DPDK-based app? 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, 12 Jan 2015 15:17:24 -0000 On 01/12/15 16:50, Neil Horman wrote: > On Mon, Jan 12, 2015 at 11:30:26AM +0000, Bruce Richardson wrote: >> On Sun, Jan 11, 2015 at 07:10:30PM +0200, Vlad Zolotarov wrote: >>> Hi, >>> guys could you share form your experience what is the best way to distribute >>> the DPDK libraries with the DPDK-based app: >>> >>> * Is there any significant benefit in compiling the libraries on a >>> target machine? >>> * Is there an already existing DPDK-libs packaging: I've noticed there >>> is some Fedora RPM package with DPDK libs but it's lacking >>> pmd-driver's libs and they are the main component we are using, >>> therefore we can't use it. >>> >>> Thanks in advance, >>> vlad >>> >> The default in DPDK is to build a statically linked binary, in which case no >> separate distribution of libraries is necessary. This also gives best performance. >> > That wasn't the question though. the question was "what is the best way to > distribute dpdk libraries". The answer is, it depends on a number of factors, > including, but not limited to what distribution your are distributing for and > what your intended audience is. > > As you note, Fedora distributes dpdk 1.7 using DSO's. We do this because Fedora > strongly tries to avoid shipping static libraries so as to prevent security > issues living on in applications that link to libraries (i.e. a dpdk security > fix will update all applications if they use DSO's. > > You've also noted that the Fedora DPDK doesn't include PMD's for several bits of > hardware. This is done because those PMD's require out of tree kernel modules, > which Fedora prohibits. So we currently only ship virtual pmd's. That will > change soon though we hope, when some high speed socket API changes get made to > the kernel. Neil, Bruce, thanks for your input. > >> If you know ahead of time what the minimum cpu hardware of your target is, it's >> probably worthwhile doing a compile of your app/libs for that minimum hardware, >> especially if you care about getting best performance. If a few percent drop in >> performance is not a big issue, then compiling up for the "default" target is >> the safest path to take. >> For distributing the libs as shared libs, the same logic applies. >> >> /Bruce >>