Thanks for the tip! This was what I experienced when I ran a separate function with periodic calls to rte_timer_manage(). The code would deadlock and stop executing after a few seconds.
Is there a way to overcome this? Perhaps by passing the core numbers into the library? -- Archit Pandey Senior Year Undergraduate Student Department of Computer Science and Engineering National Institute of Technology Karnataka Surathkal, India On Thu, 9 Apr 2020, 8:27 pm Stephen Hemminger, <[email protected]> wrote: > On Thu, 9 Apr 2020 11:37:12 +0530 > Archit Pandey <[email protected]> wrote: > > > Hello DPDK users, > > > > I'm building a library for DPDK which utilizes periodically called > > functions using the dpdk timer facility. Currently, I'm using the master > > core on an application to call timer_manage() and run the scheduled > timers. > > > > My doubt is whether its possible to call timer_manage() from inside the > > library to run the scheduled timers. This would allow for a much more > > streamlined design. An issue which comes to mind is that my library is > not > > aware of the cores it is being run on, hence I cannot use > > rte_eal_remote_launch() for a function that calls rte_timer_manage(). > > > > Any help on how I can do this would be greatly appreciated! > > > > Thanks and regards, > > > > In my experience, once you start running DPDK functions on > non-DPDK threads lots of things can break. The DPDK threads are pinned > to a core and therefore don't preempt each other. For non-DPDK threads > they are not pinned; therefore a DPDK library or other code using > rte_spinlocks can get preempted with and self-deadlock. >
