Re: [libvirt] [PATCH 2/2] rpc: Size up RPC limits

On 04/27/2012 07:22 AM, Michal Privoznik wrote: 16x increase. Are we ever going to wish for more than a megabyte? Should we be thinking about a handshaking between client and server, where they negotiate up front the largest message either is willing to receive (and where the limits may be asymmetrical)? So a message remains capped at 4 max-size strings within a struct; and in the general case where you aren't using max-size strings, you have more room for other elements in your message. Aren't there other limits we should be increasing at the same time? I can think of: REMOTE_DOMAIN_NAME_LIST_MAX (having more than 1024 guests defined, although not necessarily all running, is starting to be feasible) REMOTE_{NETWORK,INTERFACE}_NAME_LIST_MAX (256 is even more restricted, given the ability of modern cards to have multiple virtual interfaces) REMOTE_STORAGE_POOL_NAME_LIST_MAX (one pool per VM is a reasonable layout, which means it should be at least 1024 to match REMOTE_DOMAIN_NAME_LIST_MAX) REMOTE_STORAGE_VOL_NAME_LIST_MAX (some users like directories with lots of files; 1024 seems small) REMOTE_NODE_DEVICE_CAPS_LIST_MAX (16k is feeling small for some of today's super-beefy machines with lots of cpus) REMOTE_DOMAIN_{BLOCK,MEMORY}_PEEK_BUFFER_MAX (64k may still be reasonable, but why not take advantage of the larger limits for peeking more memory in fewer transactions) Any others? -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org