Re: [Xen-devel] [RFC] Proposed XenStore Interactions for Multi-Queue VIFs

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jun 27, 2013 at 11:07:36AM +0100, Andrew Bennieston wrote:
[...]
> >Grouping things together then parse this string in backend increases
> >backend complexity. If it is just something like comma / space separated
> >positioned list that would be fine (but then you need to clearly
> >document the position); if that's something more complex like a list of
> >key-value I think it would be better to have several
> >    multi-queue-hash-params-NNN-KEY -> value
> >in Xenstore, other than trying to parse complex string.
> >
> >Or even better, like the scheme you proposed for ring pages: create
> >hierarchical structure for parameters.
> 
> I intended a hierarchical structure here, e.g.
>     .../multi-queue-hash-params-alg1/key = "somekey"
>     ../multi-queue-hash-params-alg1/map = "<mapping of hash to queue
> number>"
> 
> Once the algorithm has been selected, the 'root' of this structure is
> fixed (i.e. 'multi-queue-hash-params-' concatenated with the name of the
> algorithm). The hash-dependent keys will be subkeys of that.
> 
> I can see how the language I used was unclear, though.
> 

Now I understand the subtle meaning of "grouping". My understanding was
"concatenating options into one big string" while you meant "put things
under hierachy". :-)

> >
> >>3.2 Shared ring grant references and event channels
> >>---------------------------------------------------
[...]
> >>4. Summary of main points
> >>-------------------------
> >>-   Each queue has two rings (one for Tx, one for Rx).
> >>     -   An unbalanced set of rings (e.g. more Rx than Tx) would still
> >>         leave a bottleneck on the side with fewer rings, so for
> >>         simplicity we require matched pairs.
> >>
> >>-   The frontend may only use hash algorithms that the backend
> >>     advertises; if there are no algorithms in common, frontend
> >>     initialisation fails.
> >
> >Then fall back to single queue mode (i.e. the original mode). In fact, I
> >would not expect either end to start initialising before they sort out
> >what's present and what's not. Or it's just a wording issue, I would
> >call "frontend checking available algorithms (or any other parameters)"
> >negotiation phase.
> >
> >A common trick would be frontend checks what backend offers and
> >determine whether to request this feature with a key called
> >"request-FEATURE-NAME". (yeah I know I didn't do that for split event
> >channels, sorry...).
> >
> 
> Yes, falling back to single-queue mode would be desirable here. I'm not
> sure that 'request-feature-multi-queue' is necessary, because if the
> 'multi-queue-num-queues' key is present, and has a value > 1, the
> multi-queue feature is assumed to be requested.
> 

This would do the job too. I just thought "request-XXX" has single
purpose and no implication. I don't have strong opinion on this.

> >>-   The backend must supply at least one fast hash algorithm for Linux
> >>     guests
> >>     -   Note that when Windows frontend support is added, the Toeplitz
> >>         algorithm must be supported by the backend. This is relatively
> >>         expensive to compute, however.
> >>
[...]
> >
> >Finally, just out of my curiosity, is it possible that any of the
> >parameters change when the guest is running?
> 
> There is. The Toeplitz algorithm that Windows specifies may periodically
> update the 'table' that steers different hash values to different queues
> (e.g. if it determines that one queue is being over-utilised). The
> backend is expected to respond to this change within a reasonable
> timeframe. This means that, with certain hash algorithms, the backend
> may be expected to watch a XenStore key and respond accordingly to
> changes.
> 

OK, got it.


Wei.

> Andrew.

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