Re: [PATCH v10 4/5] remus: implement remus network buffering for nic devices

[Hongyang Yang <yanghy@cn.fujitsu.com>]

On 06/06/2014 12:50 AM, Shriram Rajagopalan wrote:
> On Wed, Jun 4, 2014 at 8:34 PM, Yang Hongyang <yanghy@cn.fujitsu.com
> <mailto:yanghy@cn.fujitsu.com>> 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.