On 04/27/2012 07:22 AM, Michal Privoznik wrote: > Currently, we are allocating buffer for RPC messages statically. > This is not such pain when RPC limits are small. However, if we want > ever to increase those limits, we need to allocate buffer dynamically, > based on RPC message len (= the first 4 bytes). Therefore we will > decrease our mem usage in most cases and still be flexible enough in > corner cases. > --- > src/rpc/virnetclient.c | 16 ++- > src/rpc/virnetmessage.c | 12 ++- > src/rpc/virnetmessage.h | 6 +- > src/rpc/virnetserverclient.c | 20 ++- > tests/virnetmessagetest.c | 393 +++++++++++++++++++++++------------------- > 5 files changed, 264 insertions(+), 183 deletions(-) I haven't looked closely at this, but I do have a generic question: Are you malloc'ing and free'ing the buffer for each rpc on every call, or are you tracking a pool of buffers and only alloc'ing when needed? Furthermore, can you use the stack or a statically allocated array to receive short messages, saving alloc only for the long messages? I'm worried about performance if we malloc on every single RPC call. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list