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