> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, 25 October 2023 18.46 > > 25/10/2023 17:37, Stephen Hemminger: > > On Wed, 25 Oct 2023 17:13:14 +0200 > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > case RTE_THREAD_PRIORITY_REALTIME_CRITICAL: > > > + /* > > > + * WARNING: Real-time busy loop takes priority on kernel > threads, > > > + * making the system unstable. > > > + * There is also a known issue when using > rte_ring. > > > + */ > > > > I was thinking something like: > > > > static bool warned; > > if (!warned) { > > RTE_LOG(NOTICE, EAL, "Real time priority is unstable when > thread is polling without sleep\n"); > > warned = true; > > } > > I'm not sure about bothering users. > They can fear something is wrong even if the developer took care of it. > I think doc warnings for developers are more appropriate. > I've added notes in the API.
I agree with Thomas on this. If you want the log message, please degrade it to INFO or DEBUG level. It is only relevant when chasing problems, not for normal production - and thus NOTICE is too high. Someone might build a kernel with options to keep non-dataplane threads off some dedicated CPU cores, so they can be used for guaranteed low-latency dataplane threads. We do. We don't use real-time priority, though. For reference, we did some experiments (using this custom built kernel) with a dedicated thread doing nothing but a loop calling rte_rdtsc_precise() and registering the delta. Although the overwhelming majority is ca. CPU 80 cycles, there are some big outliers at ca. 9,000 CPU cycles. (Order of magnitude: ca. 45 of these big outliers per minute.) Apparently some kernel threads steal some cycles from this thread, regardless of our customizations. We haven't bothered analyzing and optimizing it further. I think our experiment supports the need to allow kernel threads to run, e.g. by calling sleep() or similar, when an EAL thread has real-time priority.
