>>> On 22.10.15 at 12:44, <paul.durr...@citrix.com> wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 22 October 2015 09:48 >> >>> On 20.10.15 at 14:35, <paul.durr...@citrix.com> wrote: >> > + * max-key-length: an integer value indicating the maximum key length (in >> > + * octets) that the frontend may supply. >> > + * >> > + * Upon selecting this algorithm, the frontend may supply the following >> > + * parameters. >> > + * >> > + * types: a space separated list containing none, any or all of the type >> > + * names included in the types list in the capabilities. >> > + * When the backend encounters a packet type not in this list it >> > + * will assign a hash value of 0. >> > + * >> > + * key: a ':' separated list of octets (up to the maximum length specified >> > + * in the capabilities) expressed in hexadecimal indicating the key >> > + * that should be used in the hash calculation. >> >> While I see no way around this proliferation of keys, have you >> considered the resource consumption effect? Guests have a limit on >> how much space they may consume in xenstore, and with additions >> like these it seems increasingly likely for the defaults to no longer be >> sufficient. > > I have considered it and I think it will probably mean adjustments when we > pull this into XenServer. Do you think it's worth making a change in the > default oxenstored.conf as part of this series?
Well, I've actually been looking a the C variant when replying. And whether increasing the defaults is an acceptable thing I'm not sure - after all there is a point for these limits to be there (I suppose). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
