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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: 22 October 2015 12:32
> To: Jan Beulich; Paul Durrant
> Cc: Ian Jackson; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org); Tim
> (Xen.org)
> Subject: Re: [PATCH v5 3/5] public/io/netif.h: add documentation for hash
> negotiation and mapping
> 
> 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?
> 

The other precedent for this kind of thing would be the dummy tx + extra seg 
used for multicast add/remove. I could use the gref in such a beast to point at 
a guest page and then the extra seg type say whether itâs table or key data. 
Or, I could simply replace the lists here with grefs pointing at pages 
containing the data and state that the xenstore keys will simply be re-written 
(even if there is no change in the gref) to indicate table or key updates. Any 
preferences?

  Paul

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