RE: [RFC v4 2/3] lib: add fastmem library

["Morten Brørup" <mb@smartsharesystems.com>]

> 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.