Hi,
Following is the structure of an IO request which is inserted in the shared
IO ring.
include/xen/interface/io/blkif.h
struct blkif_request {
uint8_t operation; /* BLKIF_OP_??? */
uint8_t nr_segments; /* number of segments */
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 {
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;
} seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
};
Sorry, if my questions seem obvious or trivial. I am a newbie in xen
development. Right now, me and my group are trying to understand the disk io
mechanism in XEN. We intend to modify the existing system. We expect better
performance after this modification.
So, in the above structure,
1. what is a "segment" referred in the structure.
2. Why is there an array of blkif_request_segment (why not a single
instance). What is it''s purpose?
3. In the structure blkif_request_segment, are the first_sect and last_sect
physical sector numbers
Thanks.
Paresh Nakhe
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> Hi, > Following is the structure of an IO request which is inserted in theshared IO> ring. > > include/xen/interface/io/blkif.h > > struct blkif_request { > uint8_t operation; /* BLKIF_OP_???*/> uint8_t nr_segments; /* number of segments*/> blkif_vdev_t handle; /* only for read/write requests*/> uint64_t id; /* private guest value, echoed inresp */> blkif_sector_t sector_number;/* start sector idx on disk (r/wonly) */> struct blkif_request_segment { > 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; > } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; > }; > > Sorry, if my questions seem obvious or trivial. I am a newbie in xen > development. Right now, me and my group are trying to understand thedisk io> mechanism in XEN. We intend to modify the existing system. We expectbetter> performance after this modification. > > So, in the above structure, > 1. what is a "segment" referred in the structure. > 2. Why is there an array of blkif_request_segment (why not a single > instance). What is it''s purpose? > 3. In the structure blkif_request_segment, are the first_sect andlast_sect> physical sector numbers >Each entry on the ring contains the details of the operation. Each operation is going to be either a read from memory or a write to memory. The ring entry contains a list of memory pages that are granted to Dom0. The first_sect and last_sect are worked out by thinking of each page as holding 8 sectors (page size is 4096 bytes, sectors are 512 bytes). first_sect and last_sect refer to the sector number offset inside that frame, so if the address of your buffer was offset 0 then first_sect would be 0, if it was offset 512 then first_sect would be 1, etc. Your buffer obviously has to be aligned to a 512 byte boundary (which is a pain for Windows!). Probably the best way to describe it is an example. Suppose you want to read sectors 123-134 (11 sectors) into virtual memory starting at address 0x12345600 (length 11 * 512 = 5632). You would do the following: 1. Get the pfn''s of the memory. Eg virtual address 0x12345600-0x12346BFF might map to pages 0x4444 and 0x5555 2. Get a grant ref and grant access to those pfn''s. Your grant refs might be 123 and 456 3. Set the members of the struct as follow: . operation = read . nr_segments = 2 (2 pages) . sector_number = 123 . handle = I forget what this is for... . id = your own id for you to track this request when you get the response back . seg[0].gref = 123 . seg[0].first_sect = 3 (offset 0x600 in frame) . seg[0].last_sect = 7 . seg[1].gref = 456 . seg[1].first_sect = 0 . seg[1].last_sect = 5 Please excuse any arithmetic errors I might have made above, but the logic should be right. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
That was a really nice explanation. blkif_request_segment seems to be serving the same purpose which bio structure serves in native machines. (Plz correct me if i am wrong) In your example, we are reading sectors 123-134. Is it necessary that sectors be contiguous? Also the pages to which these are mapped are shown as contiguous. Is this always the case? I haven''t understood the concept of *scatter gather request segments*clearly. Does this concept have anything do something with the question stated above? Paresh On Thu, Feb 3, 2011 at 5:45 AM, James Harper <james.harper@bendigoit.com.au>wrote:> > Hi, > > Following is the structure of an IO request which is inserted in the > shared IO > > ring. > > > > include/xen/interface/io/blkif.h > > > > struct blkif_request { > > uint8_t operation; /* BLKIF_OP_??? > */ > > uint8_t nr_segments; /* number of segments > */ > > 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 { > > 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; > > } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST]; > > }; > > > > Sorry, if my questions seem obvious or trivial. I am a newbie in xen > > development. Right now, me and my group are trying to understand the > disk io > > mechanism in XEN. We intend to modify the existing system. We expect > better > > performance after this modification. > > > > So, in the above structure, > > 1. what is a "segment" referred in the structure. > > 2. Why is there an array of blkif_request_segment (why not a single > > instance). What is it''s purpose? > > 3. In the structure blkif_request_segment, are the first_sect and > last_sect > > physical sector numbers > > > > Each entry on the ring contains the details of the operation. Each > operation is going to be either a read from memory or a write to memory. > The ring entry contains a list of memory pages that are granted to Dom0. > > The first_sect and last_sect are worked out by thinking of each page as > holding 8 sectors (page size is 4096 bytes, sectors are 512 bytes). > first_sect and last_sect refer to the sector number offset inside that > frame, so if the address of your buffer was offset 0 then first_sect > would be 0, if it was offset 512 then first_sect would be 1, etc. Your > buffer obviously has to be aligned to a 512 byte boundary (which is a > pain for Windows!). > > Probably the best way to describe it is an example. Suppose you want to > read sectors 123-134 (11 sectors) into virtual memory starting at > address 0x12345600 (length 11 * 512 = 5632). You would do the following: > > 1. Get the pfn''s of the memory. Eg virtual address 0x12345600-0x12346BFF > might map to pages 0x4444 and 0x5555 > 2. Get a grant ref and grant access to those pfn''s. Your grant refs > might be 123 and 456 > 3. Set the members of the struct as follow: > . operation = read > . nr_segments = 2 (2 pages) > . sector_number = 123 > . handle = I forget what this is for... > . id = your own id for you to track this request when you get the > response back > . seg[0].gref = 123 > . seg[0].first_sect = 3 (offset 0x600 in frame) > . seg[0].last_sect = 7 > . seg[1].gref = 456 > . seg[1].first_sect = 0 > . seg[1].last_sect = 5 > > Please excuse any arithmetic errors I might have made above, but the > logic should be right. > > James >-- *What I have is not a dream, because I will make it a reality.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel