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. 

Reply via email to