Features/network reentrant: Difference between revisions

From QEMU
No edit summary
Line 19: Line 19:
==frontend==
==frontend==
   Depend on other Qemu subsystem's re-entrant. Currently, the main blockers are memory, interrupt.
   Depend on other Qemu subsystem's re-entrant. Currently, the main blockers are memory, interrupt.
= glib OR AioContext =
  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

Revision as of 05:57, 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

frontend

 Depend on other Qemu subsystem's re-entrant. Currently, the main blockers are memory, interrupt.

glib OR AioContext

 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