From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Bennieston Subject: Re: [PATCH RESEND] netif.h: Document xen-net{back, front} multi-queue feature Date: Wed, 30 Apr 2014 10:06:05 +0100 Message-ID: <5360BCFD.7080800@citrix.com> References: <1398788104-28334-1-git-send-email-andrew.bennieston@citrix.com> <1398788375.7888.2.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WfQSv-00046C-Fi for xen-devel@lists.xenproject.org; Wed, 30 Apr 2014 09:06:09 +0000 In-Reply-To: <1398788375.7888.2.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, wei.liu2@citrix.com, david.vrabel@citrix.com List-Id: xen-devel@lists.xenproject.org On 29/04/14 17:19, Ian Campbell wrote: > On Tue, 2014-04-29 at 17:15 +0100, Andrew J. Bennieston wrote: >> From: "Andrew J. Bennieston" >> >> Document the multi-queue feature in terms of XenStore keys to be written >> by the backend and by the frontend. > > You seem to have missed my comments on v2 in > <1394714132.25873.56.camel@kazak.uk.xensource.com>, dated "Thu, 13 Mar > 2014 12:35:32 +0000". > You're right; that one must have slipped through the net. I'll fix this up and repost. Andrew > Ian. > >> >> Signed-off-by: Andrew J. Bennieston >> --- >> xen/include/public/io/netif.h | 29 +++++++++++++++++++++++++++++ >> 1 file changed, 29 insertions(+) >> >> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h >> index d7fb771..5d98734 100644 >> --- a/xen/include/public/io/netif.h >> +++ b/xen/include/public/io/netif.h >> @@ -69,6 +69,35 @@ >> */ >> >> /* >> + * Multiple transmit and receive queues: >> + * If supported, the backend will write "multi-queue-max-queues" and set its >> + * value to the maximum supported number of queues. >> + * Frontends that are aware of this feature and wish to use it can write the >> + * key "multi-queue-num-queues", set to the number they wish to use. >> + * >> + * Queues replicate the shared rings and event channels, and >> + * "feature-split-event-channels" may be used when using multiple queues. >> + * 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 them 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. >> + * >> + * Mapping of packets to queues is considered to be a function of the >> + * transmitting system (backend or frontend) and is not negotiated >> + * between the two. Guests are free to transmit packets on any queue >> + * they choose, provided it has been set up correctly. >> + */ >> + >> +/* >> * "feature-no-csum-offload" should be used to turn IPv4 TCP/UDP checksum >> * offload off or on. If it is missing then the feature is assumed to be on. >> * "feature-ipv6-csum-offload" should be used to turn IPv6 TCP/UDP checksum > >