similar to: [PATCH 0/1] vhost: add vhost_blk driver

On 2018/11/3 ??2:21, Vitaly Mayatskikh wrote: > vhost_blk is a host-side kernel mode accelerator for virtio-blk. The > driver allows VM to reach a near bare-metal disk performance. See IOPS > numbers below (fio --rw=randread --bs=4k). > > This implementation uses kiocb interface. It is slightly slower than > going directly through bio, but is simpler and also works with disk >

On 2018/11/3 ??2:21, Vitaly Mayatskikh wrote: > vhost_blk is a host-side kernel mode accelerator for virtio-blk. The > driver allows VM to reach a near bare-metal disk performance. See IOPS > numbers below (fio --rw=randread --bs=4k). > > This implementation uses kiocb interface. It is slightly slower than > going directly through bio, but is simpler and also works with disk >

On Fri, Nov 02, 2018 at 06:21:22PM +0000, Vitaly Mayatskikh wrote: > vhost_blk is a host-side kernel mode accelerator for virtio-blk. The > driver allows VM to reach a near bare-metal disk performance. See IOPS > numbers below (fio --rw=randread --bs=4k). > > This implementation uses kiocb interface. It is slightly slower than > going directly through bio, but is simpler and

On Fri, Nov 02, 2018 at 06:21:23PM +0000, Vitaly Mayatskikh wrote: > This driver accelerates host side of virtio-blk. > > Signed-off-by: Vitaly Mayatskikh <v.mayatskih at gmail.com> > --- > drivers/vhost/Kconfig | 13 ++ > drivers/vhost/Makefile | 3 + > drivers/vhost/blk.c | 510 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 526 insertions(+)

On Mon, Nov 05, 2018 at 11:15:04AM -0500, Vitaly Mayatskih wrote: > On Mon, Nov 5, 2018 at 10:48 AM Christian Borntraeger > <borntraeger at de.ibm.com> wrote: > > > For the record, we still do use virtio-blk a lot. As we see new things like discard/write zero > > support it seems that others do as well. > > Yes, trim/discard and writesame support is planned, at

On Fri, Nov 02, 2018 at 03:24:13PM -0400, Vitaly Mayatskih wrote: > On Fri, Nov 2, 2018 at 2:36 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > + if (type == VIRTIO_BLK_T_GET_ID) { > > > + char s[] = "vhost_blk"; > > > > Isn't this supposed to return the serial #? > > Yes, that gets a bit tricky here... Disk

On Fri, Nov 02, 2018 at 06:21:23PM +0000, Vitaly Mayatskikh wrote: > This driver accelerates host side of virtio-blk. Did you look at vhost-user-blk? It does things slightly differently: more of the virtio-blk device model is handled by the vhost-user device (e.g. config space). That might be necessary to implement virtio_blk_config.writeback properly. > +#define VHOST_BLK_SET_BACKEND

Hi Vitaly, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on v4.19 next-20181102] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Vitaly-Mayatskikh/vhost-add-vhost_blk-driver/20181103-084141 base:

On 2018/11/3 ??12:07, Vitaly Mayatskikh wrote: > Hi, > > I stumbled across poor performance of virtio-blk while working on a > high-performance network storage protocol. Moving virtio-blk's host > side to kernel did increase single queue IOPS, but multiqueue disk > still was not scaling well. It turned out that vhost handles events > from all virtio queues in one helper

V1->V2: -Changed dio_end_io to EXPORT_SYMBOL_GPL -Removed the own_submit blockdev dio helper -Removed the boundary change V2->V3 -Made it so we keep track of what the current logical offset in the file we have a BIO setup for so we can pass it into the submit_io hook. Because BTRFS can do RAID and such, we need our own submit hook so we can setup the bio''s in the correct fashion,

On Tue, Nov 06, 2018 at 10:45:08AM +0800, Jason Wang wrote: > > Storage industry is shifting away from SCSI, which has a scaling > > problem. > > > Know little about storage. For scaling, do you mean SCSI protocol itself? If > not, it's probably not a real issue for virtio-scsi itself. The above is utter bullshit. There is a big NVMe hype, but it is not because

Hi, Inspired by vhost-net implementation, I did initial prototype of vhost-blk to see if it provides any benefits over QEMU virtio-blk. I haven't handled all the error cases, fixed naming conventions etc., but the implementation is stable to play with. I tried not to deviate from vhost-net implementation where possible. NOTE: Only change I had to make to vhost core code is to increase

Hi, Inspired by vhost-net implementation, I did initial prototype of vhost-blk to see if it provides any benefits over QEMU virtio-blk. I haven't handled all the error cases, fixed naming conventions etc., but the implementation is stable to play with. I tried not to deviate from vhost-net implementation where possible. NOTE: Only change I had to make to vhost core code is to increase

Hi folks, [I am resending to fix the broken thread in the previous one.] This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk device accelerator. Compared to userspace virtio-blk implementation, vhost-blk gives about 5% to 15% performance improvement. Asias He (5): aio: Export symbols and struct kiocb_batch for in kernel aio usage eventfd: Export symbol

Hi folks, [I am resending to fix the broken thread in the previous one.] This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk device accelerator. Compared to userspace virtio-blk implementation, vhost-blk gives about 5% to 15% performance improvement. Asias He (5): aio: Export symbols and struct kiocb_batch for in kernel aio usage eventfd: Export symbol

From: Zach Brown <zab@zabbo.net> ocfs2''s .aio_read and .aio_write methods are changed to take iov_iter and pass it to generic functions. Wrappers are made to pack the iovecs into iters and call these new functions. Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Cc: Zach Brown <zab@zabbo.net> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker

Signed-off-by: Dave Kleikamp <dave.kleikamp at oracle.com> Acked-by: Joel Becker <jlbec at evilplan.org> Cc: Zach Brown <zab at zabbo.net> Cc: Mark Fasheh <mfasheh at suse.com> Cc: ocfs2-devel at oss.oracle.com --- fs/ocfs2/aops.h | 2 +- fs/ocfs2/file.c | 55 ++++++++++++++++++++++---------------------------- fs/ocfs2/ocfs2_trace.h | 6 +++--- 3 files

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace. This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and message flags MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket to modules. Regular read/write behaviour is unchanged. This way, code using raw sockets to inject packets into

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace. This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and message flags MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket to modules. Regular read/write behaviour is unchanged. This way, code using raw sockets to inject packets into

Tun device looks similar to a packet socket in that both pass complete frames from/to userspace. This patch fills in enough fields in the socket underlying tun driver to support sendmsg/recvmsg operations, and message flags MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket to modules. Regular read/write behaviour is unchanged. This way, code using raw sockets to inject packets into