Re: [Xen-devel] [PATCH v5 3/5] public/io/netif.h: add documentation for hash negotiation and mapping

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-10-22 at 05:00 -0600, Jan Beulich wrote:
> > > > On 22.10.15 at 12:44, <Paul.Durrant@xxxxxxxxxx> wrote:
> > > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > > Sent: 22 October 2015 09:48
> > > > > > On 20.10.15 at 14:35, <paul.durrant@xxxxxxxxxx> 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).

It's to prevent the guest consuming an arbitrary amount of resource in the
xenstored domain.

Is there not some other way this sort of "bulkish" (-ish because I'm not
sure how large these things can be) can be communicated, either via
add/remove ring operations or by a dedicated granted page or ... ?

IIRC there is also a limit on the maximum size of a key inherent in the XS
wire protocol. Maybe 2 or 4K?


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel