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

On 05/15/2012 09:04 AM, Michal Privoznik wrote: I think we've already analyzed the compatibility concerns: small command or response: no change in behavior, regardless of the mix of old or new server and client large command (for example, a 'virDomainCreate' with a huge XML): old client: fails, server never contacted new client, old server: server rejects the message, but I'm not sure what happens next - does the server still keep the connection alive? At any rate, we can't change this behavior, except perhaps to teach the client to not send large commands without first validating what the server is willing to receive new client, new server: message can now get through large response (for example, a huge capabilities XML): old server: response never sent (hence the commit message mentioning failure to even connect) new server, old client: client rejects the response, but I'm not sure what happens next - does the client drop the connection? At any rate, we can't change this behavior, except perhaps to teach the server to not send large responses without first validating what the client is willing to recieve new server, new client: message can now get through In both cases where I'm not sure what happens, I can't help but wonder if we could make the code smarter by adding a flag to the handshaking of an initial connection: When connecting, the client sets a flag stating that it is new and understands larger limits. If the server rejects the flag, then the client retries the connection without the flag, but also records that it must not send large commands, and gracefully fails up front without ever passing too much information over the RPC wire. When receiving a connection, the server checks for the new flag. If the client didn't pass the flag, then the server records that it must not send large responses, and gracefully sends error messages instead of aborting connections when encountering a situation where the response has to be huge. However, I don't know if we need this much handshaking, or if we are okay with just larger limits and declaring the mismatch to be a problem only if you are in a situation where you want large messages in the first place. And I think we can add any handshaking as a followup patch. Therefore: I still wonder if these should be larger to match REMOTE_DOMAIN_NAME_LIST_MAX, since with SRIOV devices, the notion of one virtual interface per VM makes sense. If I recall correctly, this limit was documented in src/libvirt.c; we should update that documentation to reflect the difference in limits and which version introduced the difference. At this point, I'm comfortable giving ACK to this patch, modulo the libvirt.c doc tweak, to maximize our testing time, and give us a chance to decide if we also need to add handshaking support when establishing a connection. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org