From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: [PATCH v10 4/5] remus: implement remus network
 buffering for nic devices
Date: Fri, 6 Jun 2014 09:59:47 +0800
Message-ID: <53912093.6080901@cn.fujitsu.com>
References: <1401932069-16460-1-git-send-email-yanghy@cn.fujitsu.com>
	<1401932069-16460-5-git-send-email-yanghy@cn.fujitsu.com>
	<CAP8mzPPY3dDWSvwv4FzKg3S2xYbgkDQ+kUzMmBR-DWQ9pQY2mg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAP8mzPPY3dDWSvwv4FzKg3S2xYbgkDQ+kUzMmBR-DWQ9pQY2mg@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: rshriram@cs.ubc.ca
Cc: Ian Campbell <ian.campbell@citrix.com>, Wen Congyang <wency@cn.fujitsu.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Dong Eddie <eddie.dong@intel.com>, =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>, Lai Jiangshan <laijs@cn.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

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.