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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, May 06, 2014 at 11:16:51AM +0100, Ian Campbell wrote:
> 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.

Right. I was thinking we could spell it out. Or maybe I had been
reading too many specs lately.

> 
> Ian.
>