From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Bennieston Subject: Re: [RFC] Proposed XenStore Interactions for Multi-Queue VIFs Date: Thu, 27 Jun 2013 11:11:44 +0100 Message-ID: <51CC0FE0.5080601@citrix.com> References: <51CB1DF2.8090702@citrix.com> <51CC1D0902000078000E1137@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51CC1D0902000078000E1137@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 27/06/13 10:07, Jan Beulich wrote: >>>> On 26.06.13 at 18:59, Andrew Bennieston wrote: >> 2. Backend feature advertising >> ------------------------------ >> The backend advertises the features it supports via keys of the form >> >> /local/domain/0/backend/vif/X/Y/feature-NNN = "1" >> >> where X is the domain ID and Y is the virtual network device number. >> >> In this proposal, a backend that wishes to support multi-queue VIFs >> would add the key >> >> /local/domain/0/backend/vif/X/Y/feature-multi-queue = "1" >> >> If this key exists and is set to "1", the frontend may request a >> multi-queue configuration. If the key is set to "0", or does not exist, >> the backend either does not support this feature, or it has been >> disabled. >> >> In addition to the feature flag, a backend which supports >> feature-multi-queue would advertise a maximum number of queues, via the >> key: >> >> /local/domain/0/backend/vif/X/Y/multi-queue-max-queues >> >> This value is the maximum number of supported ring pairs; each queue >> consists of a pair of rings supporting Tx (from guest) and Rx (to >> guest). The number of rings in total is twice the value of >> multi-queue-max-queues. > > I pretty much dislike this redundant advertisement - a single > key absolutely suffices here - absence of the key or a value > <= 1 are a sufficient indication of the feature not being > supported. > You're right; I explicitly did not put a 'request-feature-multi-queue' in the frontend keys for this reason, but this one slipped past! The presence of multi-queue-max-queues > 1 is certainly sufficient to advertise multi-queue support. >> 3.2 Shared ring grant references and event channels >> --------------------------------------------------- >> 3.2.1 Ring pages >> ---------------- >> It is the responsibility of the frontend to allocate one page for each >> ring (i.e. two pages for each queue) and provide a grant reference to >> each page, so that the backend may map them. In the single-queue case, >> this is done as usual with the tx-ring-ref and rx-ring-ref keys. >> >> For multi-queue, a hierarchical structure is proposed. This serves the >> dual purpose of clean separation of grant references between queues and >> allows additional mechanisms (e.g. split event channels, multi-page >> rings) to replicate their XenStore keys for each queue without name >> collisions. For each queue, the frontend should set up the following >> keys: >> >> /local/domain/X/device/vif/Y/queue-N/tx-ring-ref >> /local/domain/X/device/vif/Y/queue-N/rx-ring-ref >> >> where X is the domain ID, Y is the device ID and N is the queue number >> (beginning at zero). >> >> 3.2.2 Event channels >> -------------------- >> The upstream netback and netfront code supports >> feature-split-event-channels, allowing one channel per ring (instead of >> one channel per VIF). When multiple queues are used, the frontend must >> write either: >> >> /local/domain/X/device/vif/Y/queue-N/event-channel = "M" >> >> to use a single event channel (number M) for that queue, or >> >> /local/domain/X/device/vif/Y/queue-N/tx-event-channel = "M" >> /local/domain/X/device/vif/Y/queue-N/rx-event-channel = "L" >> >> to use split event channels (numbers L, M) for that queue. > > Other than Wei, I'm actually in favor of this model. I don't see this > adding much complexity to the parsing logic in the backend: It's a > simply loop over the requested queue count, otherwise doing the > same operations as it does currently. Indeed. I think Wei was referring to the hash-specific parameters, which will be "grouped" (but have one key per parameter) according to, e.g. /local/domain/X/device/vif/Y/multi-queue-hash-params-alg1/key = "..." /local/domain/X/device/vif/Y/multi-queue-hash-params-alg1/map = "..." Andrew