On 28 May 2013 13:53, Michael S. Tsirkin <m...@redhat.com> wrote: > Yes, you can maybe trade some of this latency for power/CPU cycles by > aggressive polling. Doing this in a way that does not waste a lot of > power would be tricky. >
For what it's worth, here is my mental model right now: Administrator budgets one CPU core for network I/O (VM and NIC). Switch uses that CPU to deliver sufficient speed (e.g. 10 M packets/sec ~ 40Gbps). Switch uses micro-sleeps to cut cpu usage to ~ 1% in idle periods. Today I really am statically provisioning a CPU core using "linux isolcpus=..." boot option, but maybe e.g. scheduling with realtime priority would work too and free up some spare cycles for running VMs. I am hoping that administrators will feel that dedicating ~6.25% total CPU (one core out of 16) for networking will be OK. Remains to be seen whether we can really deliver this kind of performance with a mix of phsical NICs and VMs, but that's the design goal.
