Re: [Xen-devel] [PATCH V4] netif.h: Document xen-net{back, front} multi-queue feature

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-05-06 at 11:14 +0100, Andrew Bennieston wrote:
> >> + *
> >> + * Queues replicate the shared rings and event channels.
> >> + * "feature-split-event-channels" may optionally be used when using
> >> + * multiple queues, but is not mandatory.
> >> + *
> >> + * Each queue consists of one shared ring pair, i.e. there must be the 
> >> same
> >> + * number of tx and rx rings.
> >> + *
> >> + * For frontends requesting just one queue, the usual event-channel and
> >> + * ring-ref keys are written as before, simplifying the backend processing
> >> + * to avoid distinguishing between a frontend that doesn't understand the
> >> + * multi-queue feature, and one that does, but requested only one queue.
> >> + *
> >> + * Frontends requesting two or more queues must not write the toplevel
> >> + * event-channel (or event-channel-{tx,rx}) and {tx,rx}-ring-ref keys,
> >> + * instead writing those keys under sub-keys having the name "queue-N" 
> >> where
> >> + * N is the integer ID of the queue for which those keys belong. Queues
> >> + * are indexed from zero. For example, a frontend with two queues and 
> >> split
> >> + * event channels may write the following set of queue-related keys:
> >> + *
> >
> > Should you say what to be done if the multi-queue-num-queues = N doesn't
> > match with the 'queue-N-1' values? Say you N=4 and there are just
> > two sub-directories: queue-0 and queue-1 ?
> 
> I haven't given any thought to what the most sensible thing to do in 
> this case is; the current implementation will bail entirely if it 
> doesn't find _all_ of the keys it expects, for _all_ of the queues 
> requested. It's possible that you might want to set up those that were 
> completely specified , ignoring the rest, but I'd rather enforce that 
> the XenStore data is self-consistent, i.e. if four queues were 
> requested, the subkeys for four queues must also be present. This makes 
> it easier to handle rogue or broken frontends (something missing or 
> contradictory? Just tear down those queues already set up, and error 
> out) and more obvious when something has gone wrong.

I think taking this all or nothing approach is completely reasonable.

Ian.


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