What is the best way to distribute a DPDK-based app?

What is the best way to distribute a DPDK-based app?

[Vlad Zolotarov]

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

Re: What is the best way to distribute a DPDK-based app?

[Bruce Richardson]

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.

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

Re: What is the best way to distribute a DPDK-based app?

[Neil Horman]

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.

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

Re: What is the best way to distribute a DPDK-based app?

[Vlad Zolotarov]

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