Gregory Haskins wrote:
If you have a request-response workload with the wire idle and latency
critical, then there's no problem having an exit per packet because
(a) there aren't that many packets and (b) the guest isn't doing any
batching, so guest overhead will swamp the hypervisor overhead.
Right, so the trick is to use an algorithm that adapts here. Batching
solves the first case, but not the second. The bidir napi thing solves
both, but it does assume you have ample host processing power to run the
algorithm concurrently. This may or may not be suitable to all
applications, I admit.
The alternative is to get a notification from the stack that the packet
is done processing. Either an skb destructor in the kernel, or my new
API that everyone is not rushing out to implement.
Right now its way way way worse than 2us. In fact, at my last reading
this was more like 3060us (3125-65). So shorten that 3125 to 67 (while
maintaining line-rate) and I will be impressed. Heck, shorten it to
80us and I will be impressed.
The 3060us thing is a timer, not cpu time.
Agreed, but its still "state of the art" from an observer perspective.
The reason "why", though easily explainable, is inconsequential to most
people. FWIW, I have seen virtio-net do a much more respectable 350us
on an older version, so I know there is plenty of room for improvement.
All I want is the notification, and the timer is headed into the nearest
landfill.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
