[dpdk-dev] CPU hog & memory leak on FreeBSD

Lewis Donzis lew at perftech.com
Mon Aug 3 21:43:05 CEST 2020


Hello. 

We've posted about this before, but I'm hoping to find someone willing to commit a patched version of lib/librte_eal/bsdapp/eal/eal_interrupts.c that corrects a memory leak and 100% CPU hog that is immediately noticeable with the i40e driver, at a minimum. We have modified this file to correct the problem, and would be happy to provide it back to whomever is a committer for this. 

The detailed explanation is: 

Currently, s etting an alarm with rte_eal_alarm_set() registers an alarm interrupt by calling rte_intr_callback_register(), which links the callback function (eal_alarm_callback) onto a list for that source and sets up a one-shot timer via kevent. Setting additional alarms links them on to the alarm_list, but also calls rte_eal_alarm_set() again, which links the callback function onto the source callback list again. 

When the alarm triggers and eal_alarm_callback() gets called, it goes down the list of pending alarms, calling as many callback functions as possible and removing each one from the list until it reaches one which has not yet expired. Once it's done, if alarm_list is not empty, it calls rte_intr_callback_register(), which then links yet another callback onto the interrupt source's list, thus creating an infinite loop. 

The problem is that the source callback list grows infinitely under this condition (essentially, when more than one alarm is queued). However, the call is necessary in order to reset the kevent timer. 

The proposed fix recognizes and leverages the fact that an alarm interrupt in FreeBSD should never have more than one callback on its list, so if rte_intr_callback_register() is called with an interrupt handle type of RTE_INTR_HANDLE_ALARM, and if such an interrupt type already has a non-empty list, then a new callback is not created, but the kevent timer is restarted properly. 

A much simpler change is possible if we don't mind the overhead of allocating, filling-in, linking, de-linking, and freeing a callback unnecessarily. This proposed change makes every attempt to avoid that overhead. 



More information about the dev mailing list