search for: max_num_vq

...insertions(+), 20 deletions(-) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index f63d358..7c3d686 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -16,6 +16,8 @@ > > #define PART_BITS 4 > > +#define MAX_NUM_VQ 16 > + > static int major; > static DEFINE_IDA(vd_index_ida); > Does it work much worse if we just use as many queues as hardware supports, allocating as much memory as necessary? > @@ -24,8 +26,8 @@ static struct workqueue_struct *virtblk_wq; > struct virtio_blk > { &...

...insertions(+), 20 deletions(-) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index f63d358..7c3d686 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -16,6 +16,8 @@ > > #define PART_BITS 4 > > +#define MAX_NUM_VQ 16 > + > static int major; > static DEFINE_IDA(vd_index_ida); > Does it work much worse if we just use as many queues as hardware supports, allocating as much memory as necessary? > @@ -24,8 +26,8 @@ static struct workqueue_struct *virtblk_wq; > struct virtio_blk > { &...

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

...+++++++++++++++++------------- 1 file changed, 50 insertions(+), 20 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index f63d358..7c3d686 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -16,6 +16,8 @@ #define PART_BITS 4 +#define MAX_NUM_VQ 16 + static int major; static DEFINE_IDA(vd_index_ida); @@ -24,8 +26,8 @@ static struct workqueue_struct *virtblk_wq; struct virtio_blk { struct virtio_device *vdev; - struct virtqueue *vq; - spinlock_t vq_lock; + struct virtqueue *vq[MAX_NUM_VQ]; + spinlock_t vq_lock[MAX_NUM_VQ]; /* Th...

...++++++++++++++++++------------ 1 file changed, 55 insertions(+), 20 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index f63d358..e0d077d 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -16,6 +16,8 @@ #define PART_BITS 4 +#define MAX_NUM_VQ 16 + static int major; static DEFINE_IDA(vd_index_ida); @@ -24,8 +26,8 @@ static struct workqueue_struct *virtblk_wq; struct virtio_blk { struct virtio_device *vdev; - struct virtqueue *vq; - spinlock_t vq_lock; + struct virtqueue *vq[MAX_NUM_VQ]; + spinlock_t vq_lock[MAX_NUM_VQ]; /* Th...

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

Hi, This patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance problems on virtio-blk device get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq

...20, 2014 at 11:29:40PM +0800, Ming Lei wrote: > > @@ -24,8 +26,8 @@ static struct workqueue_struct *virtblk_wq; > > struct virtio_blk > > { > > struct virtio_device *vdev; > > - struct virtqueue *vq; > > - spinlock_t vq_lock; > > + struct virtqueue *vq[MAX_NUM_VQ]; > > + spinlock_t vq_lock[MAX_NUM_VQ]; > > array of struct { > *vq; > spinlock_t lock; > } > would use more memory but would get us better locality. > It might even make sense to add padding to avoid > cacheline sharing between two unrelated VQs. > Want to...

...d, 55 insertions(+), 20 deletions(-) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index f63d358..e0d077d 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -16,6 +16,8 @@ > > #define PART_BITS 4 > > +#define MAX_NUM_VQ 16 It would be nice to allocate virtqueues dynamically instead of hardcoding the limit. virtio-scsi also allocates virtqueues dynamically. Stefan

...d, 55 insertions(+), 20 deletions(-) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index f63d358..e0d077d 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -16,6 +16,8 @@ > > #define PART_BITS 4 > > +#define MAX_NUM_VQ 16 It would be nice to allocate virtqueues dynamically instead of hardcoding the limit. virtio-scsi also allocates virtqueues dynamically. Stefan

...;> >> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c >> index f63d358..e0d077d 100644 >> --- a/drivers/block/virtio_blk.c >> +++ b/drivers/block/virtio_blk.c >> @@ -16,6 +16,8 @@ >> >> #define PART_BITS 4 >> >> +#define MAX_NUM_VQ 16 > > It would be nice to allocate virtqueues dynamically instead of > hardcoding the limit. virtio-scsi also allocates virtqueues > dynamically. virtio-scsi may have lots of LUN, but virtio-blk only has one disk which needn't lots of hardware queues. Also it doesn't matter...