[Qemu-devel] How to achieve low latency Win32 Tap?

[Ely Soto]

Hello,

I'm trying to figure out a way to get
the network latency on the Win32 Tap interface as low as possible since
it's required for the application I'm working on.
I'm testing it by simply using ping.

Right now the bottleneck is the fact
that the Tap thread has the wait for service from the QEMU main thread
to shuffle incoming data into the virtual machine.
On my machine that equals a range of
1-18ms pings with an average of 9ms. This is way beyond acceptable for
my needs.

Example:
1. tap_win32_thread_entry()
 Read incoming data from the Tap interface and puts it in a buffer
queue.
2. tap_win32_thread_entry()
signals a semaphore that QEMU's main_loop_wait()
periodically polls to see if service is required.
3. QEMU's main thread then executes
the callback that grabs the incoming data and calls the network client's
read callback (e.g. ne2000's ne2000_receive())
4. The data is processed in the network
clients code in the context of this thread and, yay, the virtual machine
has it's data.

The problem is that there can be a lot
of latency between the 'polling' passes made by the main thread.

On my system, I've verified that that
is the big bottleneck.

Other sources of latency
1. WaitForMultipleEvents() seems to
add enough overhead to make a difference. When I added the qemu tap callback
to the polling queue instead of the wait_object queue, latency decreased.
2. tap_win32_thread_entry()
blocking that occurs when the QEMU main thread is accessing the buffer
queue that contains the data.

--------------------------------------------------------------------------------
I've actually tried removing all interaction
with the QEMU main thread by calling the network client's callback directly
via qemu_send_packet()
from the context of tap_win32_thread_entry().
This had amazing results, reducing latency
to nil. Seemed to work fine too. Hehe
Pings had <1ms latency without any
blips at all.

Of  course this violates synchronization
checks since the network client's callback isn't thread safe. I could start
adding some Win32 CRITICAL_SECTION
protections to try and correct that. However, this would mean that the
main QEMU thread would block there occasionally.

Anyone have any insights/ideas on my
train of thought? I could use some since I'm treading unknown waters.
--------------------------------------------------------------------------------

Ely Soto

---

Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.