Features/network reentrant: Difference between revisions

From QEMU
No edit summary
 
Line 34: Line 34:
= to do =
= to do =
== For virtio net, we need memory be thread-safe ==
== For virtio net, we need memory be thread-safe ==
[[Category:Obsolete feature pages]]

Latest revision as of 08:42, 12 October 2016

benefit of network layer re-entrant

 1st,make the component of network run on multi-thread. Finally it would be omething like
  qemu -object io-thread,id=thread0 -device virtio-net,rx[0]=thread0,tx[0]=thread0
 2nd,with glib, it is easy to do unit test

network layer re-entrant includes

 re-entrant of network core 
 re-entrant of backend like tap
 re-entrant of frontend like virtio net

network core

 The thread safety issue focus on NetClientState, NetQueue and hub. 
 (proposal patches have been sent out. See:[PATCH v2 0/5] make netlayer re-entrant [1])

backend

 make glib as the event loop for backends.
 consider about the race between the iohandler and NetClientInfo callback
 (make tap as the first example)

frontend

 Depend on other Qemu subsystem's re-entrant. Currently, the main blockers are memory, interrupt.
 (make virtio net as the first example)

glib OR AioContext

disadvantage for current AioContext

 1st. need to define and expand interface for other fd events, while glib open this interface for user *
 2nd. need to add support for IOCanReadHandler, while gsource provide prepare, check method to allow more flexible control
 3rd. block layer's AioContext will block other AioContexts on the same thread.
 4th. need more document

disadvantage for glib

 1st. if more than one fds on the same GSource, need re-implement something like aio_set_file_handler

to do

For virtio net, we need memory be thread-safe