> From: Matthew Hall [mailto:mhall at mhcomputing.net] > Sent: Thursday, October 30, 2014 8:50 PM > > On Thu, Oct 30, 2014 at 09:18:23AM +0000, Gonzalez Monroy, Sergio wrote: > > I would say that D) is a good balance, although not being the simplest. > > A, or D. Depending on things such as, "If you run the DPDK on Random > Platform X," where X could be something like Power CPUs or other weird > stuff, will all of the things needed for the Combined Lib 1) be compilable, 2) > be able to load w/o errors. > > For example, I could see probe ctor functions from various PMD's blowing up > on unsupported hardware. Like how the rte_pmd_virtio had issues when I > tried it on my VM system. > IMHO the underlying issue was that virtio was unsupported for that platform. What I am trying to say is that any app built against a combined shared lib or combined/separated static lib will have that same issue if the feature/PMD is unsupported for the platform. In the virtio case, building against combined shared or combined/separated static DPDK libs would have the same result because the virtio PMD would be in the app.
> If we think we can make sure no platform specific stuff breaks when it ends > up in Combined Lib A then A is probably the easiest for all. > I agree, a combined lib would simplify all app/lib linking, making it easier for the user and less error prone. One of the downsides that comes to mind is a flow work (I think you mentioned it) where you have multiple apps building against a single DPDK copy, and each app uses different features/PMDs. In that scenario, having separated libs would make your life easier as you would not need to have multiple DPDK copies customized for each app, giving you the flexibility to hand pick each lib you want to include into your app. That flow work still presents some issues as they may be features that are incompatible between each other and would need to be in different DPDK copies. Regards, Sergio > Matthew.
