Re: [Xen-devel] [RFC] Proposed XenStore Interactions for Multi-Queue VIFs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.06.13 at 18:59, Andrew Bennieston <andrew.bennieston@xxxxxxxxxx> 
>>> 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.

> 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.

Jan


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