From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYTzj-0003Kc-8t for qemu-devel@nongnu.org; Tue, 13 Nov 2012 22:50:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYTzg-0001RN-6t for qemu-devel@nongnu.org; Tue, 13 Nov 2012 22:50:31 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:51594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYTzf-0001Qr-I1 for qemu-devel@nongnu.org; Tue, 13 Nov 2012 22:50:28 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Nov 2012 09:20:18 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAE3oBMQ23920700 for ; Wed, 14 Nov 2012 09:20:12 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAE9K3te030144 for ; Wed, 14 Nov 2012 09:20:03 GMT Message-ID: <50A314EE.6080801@linux.vnet.ibm.com> Date: Wed, 14 Nov 2012 11:50:06 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <50A313A5.8030500@linux.vnet.ibm.com> In-Reply-To: <50A313A5.8030500@linux.vnet.ibm.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] [RFC] libqblock OOM issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Stefan Hajnoczi Cc: Kevin Wolf , Blue Swirl , Anthony Liguori , qemu-devel Hello,Paolo and Stefanha In order to resolve OOM issue, I am trying wrap all APIs using sunrpc, need some suggestion before coding. There are some different way to implement, not sure which would be better: 1 keep client as thin as possible, client stores opaque pointer used in server side, for eg, QBlockContext *ctx, client only get a pointer pointing to the address where server stores really the object. This have risk when server/client crash and reconnect. 2 client and server maintains index for QBlockContext and QBlockState. 3 thick client and server layer, expose all structure details in .x file, each API have a correspond rpc call. .x file may be complex. 4 define a custom protocol on XDR, like libvirt, this may need many code in server/client side. also with method 1-3, Consider wrapping following API: int qb_context_new(QBlockContext **context); The parameter context is a pointer that will be modified, it seems sunrpc does not transfer back modified parameter by server to client, so I need to define a structure as struct qb_context_new_ret { int ret; int opaque_len; char *opaque_val; } and use that as rpc call's return structure. In this way each API wrapped need a new defined internal structure make things complicate. so I am wondering if there is a better way to do it.