> Initialization should be done at the proper DPDK startup stage, not > lazily at all fastmem functions. > In the fastmem functions, calling fastmem_assure() should be replaced > by a simple RTE_ASSERT(fastmem != NULL). > > I was wondering how do other libs handle the situation where a > secondary process depends on init performed by the primary function? > It looks like they do something similiar to fastmem_assure(). This > sucks! > That's an important feature gap in DPDK, which I already registered as > a bug on the wishlist: https://bugs.dpdk.org/show_bug.cgi?id=1913 > > Until we get that wish fixed, we should make eal depend on fastmem, and > call the fastmem init function from inside rte_eal_init().
Or maybe just keep the lazy-init for now, so we don't have to discuss EAL dependencies. You said it: "Path of least resistance." We can switch to startup-init later, and eliminate the lazy-init cost then.
