The above was recorded on an idle system. Swapper 0 176146.492200: irq:irq_handler_entry: irq=152 this case the cpu is idle (hence swapper for the process), an irq fired for an Rx queue on CPU 5, softirq processing looped twice handling 64 packets and then 27 packets before exiting with the next irq firing 229 usec later and starting the loop again. Swapper 0 176146.491971: napi:napi_poll: napi poll on napi struct 0xffff9d3d53863e88 for device eth0 work 27 budget 64 Swapper 0 176146.491942: napi:napi_poll: napi poll on napi struct 0xffff9d3d53863e88 for device eth0 work 64 budget 64 e irq:irq_handler_entry,irq:irq_handler_exit \ One way to see the above description is using perf: sudo perf record -a \ When that happens the system is a bit more transparent about the networking overhead in the sense that CPU usage can be monitored (though with the assumption that it is packet handling versus other softirqs). If the softirq vector still has more work to do after the maximum number of loops or time is reached, it defers further work to the ksoftirqd thread for that CPU. softirq cycles can be back to back, up to 10 times or 2 msec (see _do_softirq), before taking a break. Net_rx_action, the handler for network Rx traffic, usually runs really fast – like under 25 usecs – dealing with up to 64 packets per napi instance (NIC and RPS) at a time before deferring to another softirq cycle.
For example, 'top' can show a process appears to be using 99+% cpu but in reality 60% of that time is spent processing packets meaning the process is really only get 40% of the CPU to make progress on its workload. System accounting will attribute those CPU cycles to any process running at that moment even though that process is not doing any work on its behalf. Linux will process a fair amount of packets in the context of whatever is running on the CPU at the moment the irq is handled. This post looks at the cost of networking in terms of CPU cycles stolen from processes running in a host. While those are important and often telling metrics, results for such benchmarks do not tell you the impact processing those packets has on the workloads running on that system. When evaluating networking for a host the focus is typically on latency, throughput or packets per second (pps) to see the maximum load a system can handle for a given configuration.
0 kommentar(er)
