From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Keir (Xen.org)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] blkif: add indirect descriptors interface to public headers
Date: Tue, 12 Nov 2013 09:22:54 -0500 [thread overview]
Message-ID: <20131112142254.GC9306@phenom.dumpdata.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD017021D@AMSPEX01CL01.citrite.net>
On Tue, Nov 12, 2013 at 01:46:19PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> > bounces@lists.xen.org] On Behalf Of Roger Pau Monne
> > Sent: 12 November 2013 10:37
> > To: xen-devel@lists.xenproject.org
> > Cc: Keir (Xen.org); Jan Beulich; Roger Pau Monne
> > Subject: [Xen-devel] [PATCH] blkif: add indirect descriptors interface to
> > public headers
> >
> > Indirect descriptors introduce a new block operation
> > (BLKIF_OP_INDIRECT) that passes grant references instead of segments
> > in the request. This grant references are filled with arrays of
> > blkif_request_segment_aligned, this way we can send more segments in a
> > request.
> >
> > This interface is already implemented in Linux >= 3.11.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > Cc: Keir Fraser <keir@xen.org>
> > Cc: Jan Beulich <jbeulich@suse.com>
> > ---
> > xen/include/public/io/blkif.h | 51
> > +++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 51 insertions(+), 0 deletions(-)
> >
> > diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> > index b9b9d98..84eb7fd 100644
> > --- a/xen/include/public/io/blkif.h
> > +++ b/xen/include/public/io/blkif.h
> > @@ -468,6 +468,30 @@
> > #define BLKIF_OP_DISCARD 5
> >
> > /*
> > + * Recognized if "feature-max-indirect-segments" in present in the backend
> > + * xenbus info. The "feature-max-indirect-segments" node contains the
> > maximum
> > + * number of segments allowed by the backend per request. If the node is
> > + * present, the frontend might use blkif_request_indirect structs in order to
> > + * issue requests with more than BLKIF_MAX_SEGMENTS_PER_REQUEST
> > (11). The
> > + * maximum number of indirect segments is fixed by the backend, but the
> > + * frontend can issue requests with any number of indirect segments as
> > long as
> > + * it's less than the number provided by the backend. The indirect_grefs
> > field
> > + * in blkif_request_indirect should be filled by the frontend with the
> > + * grant references of the pages that are holding the indirect segments.
> > + * This pages are filled with an array of blkif_request_segment_aligned
> > + * that hold the information about the segments. The number of indirect
> > + * pages to use is determined by the maximum number of segments
> > + * an indirect request contains. Every indirect page can contain a maximum
> > + * of 512 segments (PAGE_SIZE/sizeof(blkif_request_segment_aligned)),
> > + * so to calculate the number of indirect pages to use we have to do
> > + * ceil(indirect_segments/512).
> > + *
> > + * If a backend does not recognize BLKIF_OP_INDIRECT, it should *not*
> > + * create the "feature-max-indirect-segments" node!
> > + */
> > +#define BLKIF_OP_INDIRECT 6
> > +
> > +/*
> > * Maximum scatter/gather segments per request.
> > * 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.
> > @@ -475,6 +499,11 @@
> > #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> >
> > /*
> > + * Maximum number of indirect pages to use per request.
> > + */
> > +#define BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST 8
> > +
> > +/*
> > * NB. first_sect and last_sect in blkif_request_segment, as well as
> > * sector_number in blkif_request, are always expressed in 512-byte units.
> > * However they must be properly aligned to the real sector size of the
> > @@ -517,6 +546,28 @@ struct blkif_request_discard {
> > };
> > typedef struct blkif_request_discard blkif_request_discard_t;
> >
> > +struct blkif_request_indirect {
> > + uint8_t operation; /* BLKIF_OP_INDIRECT */
> > + uint8_t indirect_op; /* BLKIF_OP_{READ/WRITE} */
> > + uint16_t nr_segments; /* number of segments */
>
> This is going to be a problem. What alignment boundary are you expecting the next field to start on? AFAIK 32-bit gcc will 4-byte align it, 32-bit MSVC will 8-byte align it.
>
Oh no. I thought that the Linux one had this set correctly, ah it did:
struct blkif_request_indirect {
uint8_t indirect_op;
uint16_t nr_segments;
#ifdef CONFIG_X86_64
uint32_t _pad1; /* offsetof(blkif_...,u.indirect.id) == 8 */
#endif
uint64_t id;
blkif_sector_t sector_number;
blkif_vdev_t handle;
uint16_t _pad2;
grant_ref_t indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];
#ifdef CONFIG_X86_64
uint32_t _pad3; /* make it 64 byte aligned */
#else
uint64_t _pad3; /* make it 64 byte aligned */
#endif
} __attribute__((__packed__));
Wheew.
> Paul
>
> > + uint64_t id; /* private guest value, echoed in resp */
> > + blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
> > + blkif_vdev_t handle; /* same as for read/write requests */
> > + grant_ref_t
> > indirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];
> > +#ifdef __i386__
> > + uint64_t pad; /* Make it 64 byte aligned on i386 */
> > +#endif
> > +};
> > +typedef struct blkif_request_indirect blkif_request_indirect_t;
> > +
> > +struct blkif_request_segment_aligned {
> > + grant_ref_t gref; /* reference to I/O buffer frame */
> > + /* @first_sect: first sector in frame to transfer (inclusive). */
> > + /* @last_sect: last sector in frame to transfer (inclusive). */
> > + uint8_t first_sect, last_sect;
> > + uint16_t _pad; /* padding to make it 8 bytes, so it's cache-aligned */
> > +};
> > +
> > struct blkif_response {
> > uint64_t id; /* copied from request */
> > uint8_t operation; /* copied from request */
> > --
> > 1.7.7.5 (Apple Git-26)
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-11-12 14:23 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 10:36 [PATCH] blkif: add indirect descriptors interface to public headers Roger Pau Monne
2013-11-12 13:46 ` Paul Durrant
2013-11-12 14:12 ` David Vrabel
2013-11-12 14:18 ` Paul Durrant
2013-11-12 14:43 ` Jan Beulich
2013-11-12 14:49 ` David Vrabel
2013-11-12 14:54 ` Roger Pau Monné
2013-11-12 14:58 ` Jan Beulich
2013-11-14 9:57 ` Roger Pau Monné
2013-11-12 14:22 ` Konrad Rzeszutek Wilk [this message]
2013-11-12 14:29 ` Ian Campbell
2013-11-12 14:42 ` Konrad Rzeszutek Wilk
2013-11-12 14:54 ` Ian Campbell
2013-11-12 15:16 ` Paul Durrant
2013-11-13 9:26 ` Ian Campbell
2013-11-13 11:07 ` Paul Durrant
2013-11-13 11:11 ` Ian Campbell
2013-11-13 11:24 ` Paul Durrant
2013-11-14 10:06 ` Roger Pau Monné
2013-11-14 10:14 ` Paul Durrant
2013-11-14 10:27 ` Roger Pau Monné
2013-11-14 10:38 ` Paul Durrant
2013-11-14 10:52 ` Roger Pau Monné
2013-11-14 11:26 ` Paul Durrant
2013-11-14 16:24 ` Konrad Rzeszutek Wilk
2013-11-14 16:26 ` Paul Durrant
2013-11-14 16:34 ` Konrad Rzeszutek Wilk
2013-11-14 16:53 ` Paul Durrant
2013-11-14 16:57 ` Konrad Rzeszutek Wilk
2013-11-14 17:13 ` Paul Durrant
2013-11-14 18:14 ` Konrad Rzeszutek Wilk
2013-11-15 8:01 ` Roger Pau Monné
2013-11-15 9:05 ` Paul Durrant
2013-11-15 9:44 ` Ian Campbell
2013-11-14 19:16 ` Paul Durrant
2013-11-15 8:04 ` Roger Pau Monné
2013-11-13 12:01 ` Konrad Rzeszutek Wilk
2013-11-28 17:02 ` Roger Pau Monné
2013-11-29 10:14 ` Jan Beulich
2013-11-29 10:28 ` Ian Campbell
2013-11-29 12:47 ` Julien Grall
2013-11-29 12:49 ` Ian Campbell
2013-12-03 9:22 ` Keir Fraser
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=20131112142254.GC9306@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Paul.Durrant@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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.