[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v10 4/5] remus: implement remus network buffering for nic devices
On 06/06/2014 12:50 AM, Shriram Rajagopalan wrote: On Wed, Jun 4, 2014 at 8:34 PM, Yang Hongyang <yanghy@xxxxxxxxxxxxxx <mailto:yanghy@xxxxxxxxxxxxxx>> wrote: 1.Add two members in libxl_domain_remus_info: netbuf: whether netbuf is enabled netbufscript: the path of the script which will be run to setup and tear down the guest's interface. 2.introduces remus-netbuf-setup hotplug script responsible for setting up and tearing down the necessary infrastructure required for network output buffering in Remus. This script is intended to be invoked by libxl for each guest interface, when starting or stopping Remus. Apart from returning success/failure indication via the usual hotplug entries in xenstore, this script also writes to xenstore, the name of the IFB device to be used to control the vif's network output. The script relies on libnl3 command line utilities to perform various ...snip... + +static void nic_postsuspend(libxl__remus_device *dev) +{ + netbuf_epoch_op(dev, tc_buffer_start); +} + +static void nic_commit(libxl__remus_device *dev) +{ + netbuf_epoch_op(dev, tc_buffer_release); +} + The async execution for each netlink call is an overkill. These rtnl calls complete in a matter of few microseconds utmost. On the other hand, this code structure, fork/execs a new process for every checkpoint just to execute a single library call (netbuf_epoch_op), which in turn issues just a syscall. Correct me if I am wrong. I am assuming that the libxl__ev_child_fork eventually leads to a fork() and exec() call. Per remus checkpoint 2 ops for netbuf, 2 for disk. 1 fork & exec per op for a total of 4 forks per checkpoint. (based on this patch and the drbd patch) At 25 checkpoints per second, you are looking at roughly a 100 fork/execs per second. Hi Shriram, thanks for review, actually the remus checkpoint do fork, and exit soon, assume the syscalls are quick. -- Thanks, Yang. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |