Features/network reentrant: Difference between revisions
No edit summary |
|||
Line 27: | Line 27: | ||
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 | ||
= to do = | |||
For virtio net, we need memory be thread-safe |
Revision as of 06:22, 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 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
to do
For virtio net, we need memory be thread-safe