Features/network reentrant: Difference between revisions

From QEMU
No edit summary
Line 23: Line 23:


= glib OR AioContext =
= glib OR AioContext =
== requirement/issue for current AioContext implement ==
== requirement/issue for current AioContext ==
   Expand G_IO_IN in AioContext, or leave a gap for user to provide dispatcher
   *Need to define and expand interface for other fd events
   Add full support for IOCanReadHandler
   *Add full support for IOCanReadHandler
   For sync reason, block layer's AioContext will block the other AioContext's dispather on the same thread
   *For sync reason, block layer's AioContext will block other AioContexts.
  *More document


= 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 06:18, 21 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

 *Need to define and expand interface for other fd events
 *Add full support for IOCanReadHandler
 *For sync reason, block layer's AioContext will block other AioContexts.
 *More document

to do

For virtio net, we need memory be thread-safe