The whole block describing multiqueue support was repeated two times. There also was some repetition in the description of the 'discard-enable' property.
Signed-off-by: Dario Faggioli <dario.faggi...@citrix.com> --- Cc: Andrew Cooper <andrew.coop...@citrix.com> Cc: George Dunlap <george.dun...@eu.citrix.com> Cc: Ian Jackson <ian.jack...@eu.citrix.com> Cc: Jan Beulich <jbeul...@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Cc: Stefano Stabellini <sstabell...@kernel.org> Cc: Wei Liu <wei.l...@citrix.com> Cc: Bob Liu <bob....@oracle.com> Cc: Roger Pau Monné <roger....@citrix.com> --- I'd say this should go in 4.8. It's an improvement, and it's harmless (it's documentation). --- xen/include/public/io/blkif.h | 55 ++--------------------------------------- 1 file changed, 3 insertions(+), 52 deletions(-) diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h index ce0dbfe..15a71e3 100644 --- a/xen/include/public/io/blkif.h +++ b/xen/include/public/io/blkif.h @@ -216,10 +216,9 @@ * Default Value: 1 * * This optional property, set by the toolstack, instructs the backend - * to offer discard to the frontend. If the property is missing the - * backend should offer discard if the backing storage actually supports - * it. This optional property, set by the toolstack, requests that the - * backend offer, or not offer, discard to the frontend. + * to offer (or not to offer) discard to the frontend. If the property + * is missing the backend should offer discard if the backing storage + * actually supports it. * * discard-alignment * Values: <uint32_t> @@ -451,54 +450,6 @@ */ /* - * Multiple hardware queues/rings: - * If supported, the backend will write the key "multi-queue-max-queues" to - * the directory for that vbd, 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" with the number they wish to use, which must be - * greater than zero, and no more than the value reported by the backend in - * "multi-queue-max-queues". - * - * 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 and ring-ref keys, instead writing those keys under sub-keys - * having the name "queue-N" where N is the integer ID of the queue/ring for - * which those keys belong. Queues are indexed from zero. - * For example, a frontend with two queues must write the following set of - * queue-related keys: - * - * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" - * /local/domain/1/device/vbd/0/queue-0 = "" - * /local/domain/1/device/vbd/0/queue-0/ring-ref = "<ring-ref#0>" - * /local/domain/1/device/vbd/0/queue-0/event-channel = "<evtchn#0>" - * /local/domain/1/device/vbd/0/queue-1 = "" - * /local/domain/1/device/vbd/0/queue-1/ring-ref = "<ring-ref#1>" - * /local/domain/1/device/vbd/0/queue-1/event-channel = "<evtchn#1>" - * - * It is also possible to use multiple queues/rings together with - * feature multi-page ring buffer. - * For example, a frontend requests two queues/rings and the size of each ring - * buffer is two pages must write the following set of related keys: - * - * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" - * /local/domain/1/device/vbd/0/ring-page-order = "1" - * /local/domain/1/device/vbd/0/queue-0 = "" - * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = "<ring-ref#0>" - * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = "<ring-ref#1>" - * /local/domain/1/device/vbd/0/queue-0/event-channel = "<evtchn#0>" - * /local/domain/1/device/vbd/0/queue-1 = "" - * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = "<ring-ref#2>" - * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = "<ring-ref#3>" - * /local/domain/1/device/vbd/0/queue-1/event-channel = "<evtchn#1>" - * - */ - -/* * STATE DIAGRAMS * ***************************************************************************** _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
