On Thu, Apr 18 2013, Roger Pau Monné wrote:
> On 18/04/13 16:26, Jens Axboe wrote:
> >>> I've just set that to something that brings a performance benefit
> >>> without having to map an insane number of persistent grants in
> >>> blkback.
> >>>
> >>> Yes, the values are
On 18/04/13 16:26, Jens Axboe wrote:
>>> I've just set that to something that brings a performance benefit
>>> without having to map an insane number of persistent grants in blkback.
>>>
>>> Yes, the values are correct, but the device request queue (rq) is only
>>> able to
On Thu, Apr 18 2013, Roger Pau Monné wrote:
> On 18/04/13 14:43, Jens Axboe wrote:
> > On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
> >>> On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
> >> Perhaps the xen-blkfront
On 18/04/13 14:43, Jens Axboe wrote:
> On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
>> On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
>>> On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
>> Perhaps the xen-blkfront part of the patch should be just split out to
>>
On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
> > On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
> > >>> Perhaps the xen-blkfront part of the patch should be just split out to
> > >>> make
> > >>> this easier?
> > >>>
> > >>>
On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
Perhaps the xen-blkfront part of the patch should be just split out to
make
this easier?
Perhaps what we really
On 18/04/13 14:43, Jens Axboe wrote:
On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
Perhaps the xen-blkfront part of the patch should be just split out to
make
this easier?
On Thu, Apr 18 2013, Roger Pau Monné wrote:
On 18/04/13 14:43, Jens Axboe wrote:
On Wed, Apr 17 2013, Konrad Rzeszutek Wilk wrote:
On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
Perhaps the xen-blkfront part of the patch
On 18/04/13 16:26, Jens Axboe wrote:
I've just set that to something that brings a performance benefit
without having to map an insane number of persistent grants in blkback.
Yes, the values are correct, but the device request queue (rq) is only
able to provide read requests with 64 segments
On Thu, Apr 18 2013, Roger Pau Monné wrote:
On 18/04/13 16:26, Jens Axboe wrote:
I've just set that to something that brings a performance benefit
without having to map an insane number of persistent grants in
blkback.
Yes, the values are correct, but the device request queue (rq) is
On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
> On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
> >>> Perhaps the xen-blkfront part of the patch should be just split out to
> >>> make
> >>> this easier?
> >>>
> >>> Perhaps what we really should have is just the 'max' value of
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
>>> Perhaps the xen-blkfront part of the patch should be just split out to make
>>> this easier?
>>>
>>> Perhaps what we really should have is just the 'max' value of megabytes
>>> we want to handle on the ring.
>>>
>>> As right now 32 ring requests
> >> +struct blkif_x86_32_request_indirect {
> >> + uint8_tindirect_op;
> >> + uint16_t nr_segments;
> >
> > This needs to be documented. Is there are limit to what it can be? What if
> > the frontend sets it to 1231231?
>
> This is checked in dispatch_rw_block_io:
>
> if
+struct blkif_x86_32_request_indirect {
+ uint8_tindirect_op;
+ uint16_t nr_segments;
This needs to be documented. Is there are limit to what it can be? What if
the frontend sets it to 1231231?
This is checked in dispatch_rw_block_io:
if (unlikely(nseg == 0
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
Perhaps the xen-blkfront part of the patch should be just split out to make
this easier?
Perhaps what we really should have is just the 'max' value of megabytes
we want to handle on the ring.
As right now 32 ring requests * 32 segments = 4MB.
On Wed, Apr 17, 2013 at 07:04:51PM +0200, Roger Pau Monné wrote:
On 17/04/13 16:25, Konrad Rzeszutek Wilk wrote:
Perhaps the xen-blkfront part of the patch should be just split out to
make
this easier?
Perhaps what we really should have is just the 'max' value of megabytes
we want to
On Wed, Mar 27, 2013 at 12:10:43PM +0100, Roger Pau Monne wrote:
> 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
On Wed, Mar 27, 2013 at 12:10:43PM +0100, Roger Pau Monne wrote:
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
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.
The proposed implementation
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.
The proposed implementation
20 matches
Mail list logo
