4 ms·
NAPI is not busy poll, though, and the way the article is worded suggests it's about NAPI. Now, NAPI already was supposed to have some adaptiveness involved, s
by p_l 2y ago
NAPI is not busy poll, though, and the way the article is worded suggests it's about NAPI.
Now, NAPI already was supposed to have some adaptiveness involved, so I guess it's possibly a matter of optimizing it.
But my system is compiling for now so will look at article more in depth later :V
- Denvercoder9 2y agoThe article is terrible, this doesn't affect the default NAPI behaviour. See the LWN link posted elsewhere for a more detailed, technical discussion. From the patch set itself: > If this [new] parameter is set to a non-zero value and a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred.
- deleted 2y ago[deleted]