On 03/15/2012 11:48 AM, Daniel P. Berrange wrote: > Using the sequence of RPC calls to iterate over this is only > addressing that second part of memory usage. So I'm not really > feeling that's a huge win, given the complexity it introduces. > > I'm inclined to say, that if people are creating setups with > 1000's of volume & guests, then they can probably spare the > extra memory for us to increase the main RPC message payload > limit somewhat. Our own docs/internals/rpc.html.in states: > Although the protocol itself defines many arbitrary sized data values in the > payloads, to avoid denial of service attack there are a number of size limit > checks prior to encoding or decoding data. There is a limit on the maximum > size of a single RPC message, limit on the maximum string length, and limits > on any other parameter which uses a variable length array. These limits can > be raised, subject to agreement between client/server, without otherwise > breaking compatibility of the RPC data on the wire. Increasing limits makes sense, as long as we have a sane way to do it while ensuring that on version mismatch, a large packet from the sender doesn't crash an older receiver expecting the smaller limit. In our XDR, should we be converting some of our 'type name<LIST_MAX>' over to 'type name<>' notations, to state that they are effectively unlimited within the larger bounds of the overall packet size? Is 256k for overall packet size still okay for the problem at hand? -- 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