08/11/2023 12:51, Bruce Richardson: > On Thu, Nov 02, 2023 at 11:19:24AM -0700, Rahul Gupta wrote: > > From: Rahul Gupta <rahulg...@microsoft.com> > > > > Initialization often requires rte_eal_init + rte_pktmbuf_pool_create > > which can consume a total time of 500-600 ms: > > a) For many devices FLR may take a significant chunk of time > > (200-250 ms in our use-case), this FLR is triggered during device > > probe in rte_eal_init(). > > b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for > > applications that require huge memory. > > > > This cost is incurred on each restart (which happens in our use-case > > during binary updates for servicing). > > This patch provides an optimization using pthreads that appplications > > can use and which can save 200-230ms. > > > > In this patch, rte_eal_init() is refactored into two parts- > > a) 1st part is dependent code ie- it’s a perquisite of the FLR and > > mempool creation. So this code needs to be executed before any > > pthreads. Its named as rte_eal_init_setup() > > b) 2nd part of code is independent code ie- it can execute in parallel > > to mempool creation in a pthread. Its named as rte_probe_and_ioctl(). > > > > Existing applications require no changes unless they wish to leverage > > the optimization. > > > > If the application wants to use pthread functionality, it should call- > > a) rte_eal_init_setup() then create two or more pthreads- > > b) in one pthread call- rte_probe_and_ioctl(), > > c) second pthread call- rte_pktmbuf_pool_create() > > d) (optional) Other pthreads for any other independent function. > > > > Signed-off-by: Rahul Gupta <rahulg...@linux.microsoft.com> > > Reading the description, this seems an interesting idea, and a good saving. > > If I may, I wonder if I can suggest a slight alternative. Rather than > splitting EAL init into two functions like that, how about providing an > "rte_eal_init_async()" function, which does part 1, and then spawns a > thread for part 2, before returning. We can then provide an > rte_eal_init_done() [or eal_init_async_done()] function to allow apps to > resync and check for EAL being done. > > The reason for suggesting this is that the naming and purpose of the APIs > may be a little clearer for the end user. Allowing the async init function > to create threads also allows possible future parallelism in the function > itself. For example, we could do probing of the devices themselves in > parallel.
I like the idea of async init.
