The DPDK operates (or at least it did the last time I looked) in a run to completion model for packets received. once the current batch of received packets has been processed by a thread, the DPDK run time immediately looks for more packets to process. The number of polling threads is configurable, and often there are multiple threads per network interface (esp. on 10 gig or faster interfaces) with recieve flow steering to direct related packets to the same receiving thread to maintain cache coherency during packet processing.

If you have long-lived work that shouldn't block processing more packets, it would be typical to offload that to separate thread/process from the one doing the packet processing (e.g., for control plane work).