From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH V4] netif.h: Document xen-net{back, front} multi-queue feature Date: Tue, 6 May 2014 15:19:40 -0400 Message-ID: <20140506191940.GB8721@phenom.dumpdata.com> References: <1399048437-24390-1-git-send-email-andrew.bennieston@citrix.com> <20140502195700.GA6080@phenom.dumpdata.com> <5368B613.9080404@citrix.com> <1399371411.3014.54.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Whku6-0008Da-2m for xen-devel@lists.xenproject.org; Tue, 06 May 2014 19:19:50 +0000 Content-Disposition: inline In-Reply-To: <1399371411.3014.54.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, paul.durrant@citrix.com, Andrew Bennieston , wei.liu2@citrix.com, david.vrabel@citrix.com List-Id: xen-devel@lists.xenproject.org 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. >