Features/network reentrant: Difference between revisions

From QEMU
No edit summary
No edit summary
 
(18 intermediate revisions by one other user not shown)
Line 1: Line 1:
The network layer re-entrant includes the following efforts:
= 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


  re-entrant for network core
= network layer re-entrant includes =
  re-entrant for backend like tap
  re-entrant for frontend like virtio net


network core
  re-entrant of network core  
   The thread-safety of NetClientState, NetQueue and hub. (proposal patches have been sent out)
   re-entrant of backend like tap
  re-entrant of frontend like virtio net


backend
==network core==
   using glib as the event loop to make them thread safe
   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 [http://www.mail-archive.com/qemu-devel@nongnu.org/msg159336.html])


frontend
==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.
   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
= to do =
== 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

to do

For virtio net, we need memory be thread-safe