> -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Aaron Conole > Sent: Monday, January 11, 2016 6:51 PM > To: Zoltan Kiss > Cc: dev@openvswitch.org; Flavio Leitner > Subject: Re: [ovs-dev] [PATCH v2 2/3] netdev-dpdk: Convert initialization > from cmdline to db > > Zoltan Kiss <zoltan.k...@linaro.org> writes: > > On 08/01/16 16:31, Aaron Conole wrote: > >> 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. > > > > I couldn't find the original email where this discussion happened: why > > is it required to be able to init DPDK on the fly? I mean it's a nice > > bit, but brings in a lot of trouble. On the other hand, asking the > > user to set a "other_config:odp=true" and then restart ovs-vswitchd is > > not a huge thing to ask. > > You won't find such a discussion - it's never been "required," as > such. It is very desirable, as having such automatic behavior reduces the > amount of steps required to get up and running with DPDK enabled > OVS. This is, imho, the argument of both Panu and Kevin when they think > a big on/off switch is less than elegant. I tend to agree with that, as well. > > If the user is going through the trouble of compiling with DPDK support, and > then wants to add a DPDK port, having to also set > "other_config:dpdk=yes" seems like too many ok dialogs. I hope the > analogy makes sense. > > That said, it's really an unneeded enhancement, and I've pitched the > idea to folks at the office within my elastic-shooting range. The answer > has been consistently "This is an enhancement, not a requirement." So > I'll drop the lazy-init feature for now. > > >> 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? > > As I wrote above, the 'second' part of this is a great follow up > enhancement, but for now I'm going to go back to the giant flag, and we > can take it as 'future development'.
I think we all agree that removing the vswitchd dpdk mandatory cmdline args by putting them in the db/code with defaults is good for usability and getting that alone enabled through this patch would be a good outcome IMHO. I see "other_config:dpdk=yes" and lazy init's as ways to enable a common build. That's good for usability and support but I think it's a separate enough change to warrant a separate patchset/discussion. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
