[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 04/27/2012 07:22 AM, Michal Privoznik wrote:
> Since we are allocating RPC buffer dynamically, we can increase limits
> for max. size of RPC message and RPC string. This is needed to cover
> some corner cases where libvirt is run on such huge machines that their
> capabilities XML is 4 times bigger than our current limit. This leaves
> users with inability to even connect.
> ---
>  src/remote/remote_protocol.x |    2 +-
>  src/rpc/virnetprotocol.x     |    6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)

> +++ b/src/remote/remote_protocol.x
> @@ -65,7 +65,7 @@
>   * This is an arbitrary limit designed to stop the decoder from trying
>   * to allocate unbounded amounts of memory when fed with a bad message.
>   */
> -const REMOTE_STRING_MAX = 65536;
> +const REMOTE_STRING_MAX = 1048576;

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)?

> +++ b/src/rpc/virnetprotocol.x
> @@ -45,13 +45,13 @@
>  /*----- Data types. -----*/
>  /* Maximum total message size (serialised). */
> -const VIR_NET_MESSAGE_MAX = 262144;
> +const VIR_NET_MESSAGE_MAX = 4194304;

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_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)

reasonable, but why not take advantage of the larger limits for peeking
more memory in fewer transactions)

Any others?

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]