On Fri, Oct 14, 2016 at 10:23:31AM +0200, Olivier Matz wrote: > Hi Jean, > > I'm not really fan of this. I think the configuration and build system > of primary and secondaries should be the same to avoid this kind of > issues.
You are not going to convert all existing applications to the DPDK build system. I believe that restricting the build system is irrealistic, it would restrict DPDK secondary only to toy examples. Note that libdpdk.a is tricky to use outside the DPDK build system and require some quirks even for primary applications (see Snort DPDK patches). I would say that DPDK is not very friendly to foreign applications and their build system in general. > Some other issues may happen if the configuration is different, > for instance the size of structures may be different. Impossible, because then libdpdk.a would not work. Remember we are talking of using the exact same libdpdk.a in primary and secondary, and therefore any structure used in libdpdk.a has to match. And the structures used in the app has to match libdpdk.a as well. > There is already a lot of mess due to primary/secondary at many places > in the code, I'm not sure adding more is really desirable. Yes, one solution is obviously to get rid of secondary entirely. Personally, I believe it's pretty close to working, the number of issues I found is manageable. I have a complex application (Snort) working that way without any issues. If DPDK wants to support secondary, you might as well make it work for everybody. We could discuss better solutions to those issues. For example, the tailq subsystem has a better solution. But, I'm not going to waste time if secondary is deprecated. > Regards, > Olivier Regards, Jean