Features/network reentrant: Difference between revisions
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