From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin T. Gibbs" <justing@spectralogic.com>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 4 of 4 v3] blkif.h: Define and document the request number/size/segments extension
Date: Tue, 21 Feb 2012 09:22:04 -0500 [thread overview]
Message-ID: <20120221142204.GF11950@phenom.dumpdata.com> (raw)
In-Reply-To: <a777cbc5f48b1547eb33.1329761245@ns1.eng.sldomain.com>
On Mon, Feb 20, 2012 at 11:07:25AM -0700, Justin T. Gibbs wrote:
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has changed. Drivers must be updated
> to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being
> recompiled with a __XEN_INTERFACE_VERSION greater than or equal to
> this value.
>
> This extension first appeared in the FreeBSD Operating System.
>
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
>
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/io/blkif.h
> --- a/xen/include/public/io/blkif.h Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/io/blkif.h Mon Feb 20 11:03:01 2012 -0700
> @@ -145,6 +145,32 @@
> * The maximum supported size of the request ring buffer in units of
> * machine pages. The value must be a power of 2.
> *
> + * max-requests <uint32_t>
> + * Default Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + * Maximum Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + * The maximum number of concurrent, logical requests that will be
> + * issued by the backend.
Don't you mean responses?
> + *
> + * Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + * Values: <uint8_t>
> + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + * Maximum Value: BLKIF_MAX_SEGMENTS_PER_REQUEST
> + *
> + * The maximum value of blkif_request.nr_segments supported by
> + * the backend.
> + *
> + * max-request-size
> + * Values: <uint32_t>
> + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + * Maximum Value: BLKIF_MAX_SEGMENTS_PER_REQUEST * PAGE_SIZE
> + *
> + * The maximum amount of data, in bytes, that can be referenced by a
> + * request type that accesses frontend memory (currently BLKIF_OP_READ,
> + * BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
So just to make sure my math is correct. That would be 1MB right?
> + *
> *------------------------- Backend Device Properties -------------------------
> *
> * discard-aligment
> @@ -242,6 +268,33 @@
> * The size of the frontend allocated request ring buffer in units of
> * machine pages. The value must be a power of 2.
> *
> + * max-requests
> + * Values: <uint32_t>
> + * Default Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE)
> + * Maximum Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages)
> + *
> + * The maximum number of concurrent, logical requests that will be
> + * issued by the frontend.
> + *
> + * Note: A logical request may span multiple ring entries.
> + *
> + * max-request-segments
> + * Values: <uint8_t>
> + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> + * Maximum Value: MIN(255, backend/max-request-segments)
Um, that looks like its referencing itself? This is the backend section.
> + *
> + * The maximum value the frontend will set in the
> + * blkif_request.nr_segments field.
> + *
> + * max-request-size
> + * Values: <uint32_t>
> + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE
> + * Maximum Value: max-request-segments * PAGE_SIZE
> + *
> + * The maximum amount of data, in bytes, that can be referenced by
> + * a request type that accesses frontend memory (currently BLKIF_OP_READ,
> + * BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER).
> + *
> *------------------------- Virtual Device Properties -------------------------
> *
> * device-type
> @@ -403,11 +456,28 @@
> #define BLKIF_OP_DISCARD 5
>
> /*
> - * Maximum scatter/gather segments per request.
> + * Maximum scatter/gather segments associated with a request header block.
> * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
> * NB. This could be 12 if the ring indexes weren't stored in the same page.
> */
> -#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> +#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK 11
> +
> +/*
> + * Maximum scatter/gather segments associated with a segment block.
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK 14
> +
> +#if __XEN_INTERFACE_VERSION__ >= 0x00040201
> +/*
> + * Maximum scatter/gather segments per request (header + segment blocks).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST 255
> +#else
> +/*
> + * Maximum scatter/gather segments per request (header block only).
> + */
> +#define BLKIF_MAX_SEGMENTS_PER_REQUEST BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
> +#endif
>
> /*
> * NB. first_sect and last_sect in blkif_request_segment, as well as
> @@ -422,9 +492,25 @@ struct blkif_request_segment {
> /* @last_sect: last sector in frame to transfer (inclusive). */
> uint8_t first_sect, last_sect;
> };
> +typedef struct blkif_request_segment blkif_request_segment_t;
>
> /*
> * Starting ring element for any I/O request.
> + *
> + * One or more segment blocks can be inserted into the request ring
> + * just after a blkif_request_t, allowing requests to operate on
> + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST.
> + *
> + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments
> + * to determine the number of contiguous ring entries associated
> + * with this request.
> + *
> + * Note: Due to the way Xen request rings operate, the producer and
> + * consumer indices of the ring must be incremented by the
> + * BLKIF_SEGS_TO_BLOCKS() value of the associated request.
> + * (e.g. a response to a 3 ring entry request must also consume
> + * 3 entries in the ring, even though only the first ring entry
> + * in the response has any data.)
> */
> struct blkif_request {
> uint8_t operation; /* BLKIF_OP_??? */
> @@ -432,11 +518,22 @@ struct blkif_request {
> blkif_vdev_t handle; /* only for read/write requests */
> uint64_t id; /* private guest value, echoed in resp */
> blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
> - struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> + blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
> };
> typedef struct blkif_request blkif_request_t;
>
> /*
> + * A segment block is a ring request structure that contains only
> + * segment data.
> + *
> + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request)
> + */
> +struct blkif_segment_block {
> + blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK];
> +};
> +typedef struct blkif_segment_block blkif_segment_block_t;
> +
> +/*
> * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
> * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
> */
> @@ -473,6 +570,21 @@ typedef struct blkif_response blkif_resp
> */
> DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response);
>
> +/*
> + * Index to, and treat as a segment block, an entry in the ring.
> + */
> +#define BLKRING_GET_SEG_BLOCK(_r, _idx) \
> + (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg)
> +
> +/*
> + * The number of ring request blocks required to handle an I/O
> + * request containing _segs segments.
> + */
> +#define BLKIF_SEGS_TO_BLOCKS(_segs) \
> + ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) \
> + + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1)) \
> + / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1)
> +
> #define VDISK_CDROM 0x1
> #define VDISK_REMOVABLE 0x2
> #define VDISK_READONLY 0x4
> diff -r 09051133e2fe -r a777cbc5f48b xen/include/public/xen-compat.h
> --- a/xen/include/public/xen-compat.h Mon Feb 20 11:02:53 2012 -0700
> +++ b/xen/include/public/xen-compat.h Mon Feb 20 11:03:01 2012 -0700
> @@ -27,7 +27,7 @@
> #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
> #define __XEN_PUBLIC_XEN_COMPAT_H__
>
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040201
>
> #if defined(__XEN__) || defined(__XEN_TOOLS__)
> /* Xen is built with matching headers and implements the latest interface. */
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2012-02-21 14:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 18:07 [PATCH 0 of 4 v3] blkif.h: Document protocol and existing extensions Justin T. Gibbs
2012-02-20 18:07 ` [PATCH 1 of 4 v3] blkif.h: Miscelaneous style fixes Justin T. Gibbs
2012-02-21 14:10 ` Konrad Rzeszutek Wilk
2012-02-21 14:15 ` Ian Campbell
2012-02-20 18:07 ` [PATCH 2 of 4 v3] blkif.h: Provide more complete documentation of the blkif interface Justin T. Gibbs
2012-02-21 14:10 ` Konrad Rzeszutek Wilk
2012-02-21 20:59 ` Justin T. Gibbs
2012-02-21 21:36 ` Konrad Rzeszutek Wilk
2012-02-22 11:14 ` Ian Campbell
2012-02-23 18:50 ` Konrad Rzeszutek Wilk
2012-02-23 22:41 ` Justin T. Gibbs
2012-02-21 14:27 ` Ian Campbell
2012-02-21 18:14 ` Justin T. Gibbs
2012-02-21 19:41 ` Ian Campbell
2012-02-20 18:07 ` [PATCH 3 of 4 v3] blkif.h: Document the RedHat and Citrix blkif multi-page ring extensions Justin T. Gibbs
2012-02-21 14:12 ` Konrad Rzeszutek Wilk
2012-02-21 14:32 ` Ian Campbell
2012-02-20 18:07 ` [PATCH 4 of 4 v3] blkif.h: Define and document the request number/size/segments extension Justin T. Gibbs
2012-02-21 14:22 ` Konrad Rzeszutek Wilk [this message]
2012-02-21 18:11 ` Justin T. Gibbs
2012-02-21 14:38 ` Ian Campbell
2012-02-21 18:03 ` Justin T. Gibbs
2012-02-21 19:42 ` Ian Campbell
2012-02-21 14:02 ` [PATCH 0 of 4 v3] blkif.h: Document protocol and existing extensions Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120221142204.GF11950@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=justing@spectralogic.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.