Features/network reentrant: Difference between revisions
No edit summary |
|||
| (5 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
= benefit of network layer re-entrant = | = benefit of network layer re-entrant = | ||
make the component of network run on multi-thread | 1st,make the component of network run on multi-thread. Finally it would be omething like | ||
with glib, it is easy to do unit test | qemu -object io-thread,id=thread0 -device virtio-net,rx[0]=thread0,tx[0]=thread0 | ||
2nd,with glib, it is easy to do unit test | |||
= network layer re-entrant includes = | = network layer re-entrant includes = | ||
| Line 23: | Line 24: | ||
= glib OR AioContext = | = glib OR AioContext = | ||
== | == disadvantage for current AioContext == | ||
1st. need to define and expand interface for other fd events, while glib open this interface for user * | |||
2nd. need to add support for IOCanReadHandler, while gsource provide prepare, check method to allow more flexible control | |||
3rd. block layer's AioContext will block other AioContexts on the same thread. | |||
4th. need more document | |||
== disadvantage for glib == | |||
1st. if more than one fds on the same GSource, need re-implement something like aio_set_file_handler | |||
= to do = | = to do = | ||
== For virtio net, we need memory be thread-safe == | == For virtio net, we need memory be thread-safe == | ||
[[Category:Obsolete feature pages]] | |||
Latest revision as of 08:42, 12 October 2016
benefit of network layer re-entrant
1st,make the component of network run on multi-thread. Finally it would be omething like qemu -object io-thread,id=thread0 -device virtio-net,rx[0]=thread0,tx[0]=thread0 2nd,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
disadvantage for current AioContext
1st. need to define and expand interface for other fd events, while glib open this interface for user * 2nd. need to add support for IOCanReadHandler, while gsource provide prepare, check method to allow more flexible control 3rd. block layer's AioContext will block other AioContexts on the same thread. 4th. need more document
disadvantage for glib
1st. if more than one fds on the same GSource, need re-implement something like aio_set_file_handler