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

Actually, one more slightly radical thought... Maybe add a new ring type... A 
command ring, as well as RX and TX rings? This could be used to issue key and 
table update commands to the backend and would be there for other uses in 
future.

  Paul

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