Panu Matilainen <pmati...@redhat.com> writes: > On 01/04/2016 11:46 PM, Aaron Conole wrote: >> Existing DPDK integration is provided by use of command line options which >> must be split out and passed to librte in a special manner. However, this >> forces any configuration to be passed by way of a special DPDK flag, and >> interferes with ovs+dpdk packaging solutions. >> >> This commit delays dpdk initialization until the first DPDK netdev is added >> to the bridge, at which point ovs initializes librte. > > On thing to keep in mind is that rte_eal_init() can and will tear down > the entire process on failure since DPDK calls rte_panic() if > something so much as sneezes. In current OVS this occurs on service > startup where its relatively harmless, but with lazy initialization > there could be already be other activity that is in risk of getting > terminated when the first DPDK port is added. > > Fixing rte_eal_init() to gracefully return on failure has been > discussed, and agreed on in principle, on DPDK list but all current > DPDK versions are nasty wrt that. > > - Panu -
So, I've waffled back and forth on this. I understand the reason to be nervous about an always init option (because that wastes lots of resources when the system won't ever use dpdk). I also understand the possible issues *today* with dpdk_init, but even then, it's a dpdk issue which we want fixed anyway, so I don't know that this should hold up this patch. It's definitely a more elegant solution to do the lazy init, but I think there could be times where we want a "stop everything" button for occasions where testing without DPDK doing it's thing are desired. However, I think I've come up with a solution that gives us flexibility to support these cases without much additional work, so let me know what you think: First, go back to the dpdk true/false flag Second, add a patch in the series which changes true/false to a tristate on/off/lazy allowing the policy of when to initialize DPDK to be user defined. We can default it to 'off' or 'lazy', but it can be changed to 'on' if we want. What do folks think? Too much work and code for not enough gains? Thanks, Aaron PS: Thanks for looking at this, Panu! _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
