Re: [dpdk-dev] What is the best way to distribute a DPDK-based app?

[Vlad Zolotarov <vladz@cloudius-systems.com>]

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
>>