Features/network reentrant: Difference between revisions

From QEMU
No edit summary
Line 23: Line 23:


= glib OR AioContext =
= glib OR AioContext =
== requirement for current AioContext implement ==
== requirement/issue for current AioContext implement ==
   Expand G_IO_IN in AioContext, or leave a gap for user to provide dispatcher
   Expand G_IO_IN in AioContext, or leave a gap for user to provide dispatcher
   Add full support for IOCanReadHandler
   Add full support for IOCanReadHandler
   For sync reason, block layer's AioContext will block the other AioContext's dispather
   For sync reason, block layer's AioContext will block the other AioContext's dispather on the same thread


= to do =
= to do =
== For virtio net, we need memory be thread-safe ==
== For virtio net, we need memory be thread-safe ==

Revision as of 07:15, 15 March 2013

benefit of network layer re-entrant

 make the component of network run on multi-thread
 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

requirement/issue for current AioContext implement

 Expand G_IO_IN in AioContext, or leave a gap for user to provide dispatcher
 Add full support for IOCanReadHandler
 For sync reason, block layer's AioContext will block the other AioContext's dispather on the same thread

to do

For virtio net, we need memory be thread-safe