Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp750839imw; Wed, 13 Jul 2022 07:21:48 -0700 (PDT) X-Google-Smtp-Source: AGRyM1str4KmKHgsLTwfBPUoC5ZUbrzWxaxsjz6t1CQwCfxGOYHo1wkyvk0LZO5+qlVYQvC/kgb0 X-Received: by 2002:a05:6402:3492:b0:43a:d1f0:978e with SMTP id v18-20020a056402349200b0043ad1f0978emr5455961edc.306.1657722107939; Wed, 13 Jul 2022 07:21:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657722107; cv=none; d=google.com; s=arc-20160816; b=rKWXBbtEDFur+SOqlgIGGkZsOsIPiEgHHhUplCoNKhVb1IBw92TyRMIowYDwYk1upl NirE02DlXki9pPxHm3QMcRQPU+hzaJ3SxVBtb4JfMWHK7tFk7GVEXc0uZSX127I+oZI5 dE4aJZpNes2E6p1i9Yeuh7zhrtLAoorExhudsR57zeU1b3V/X6/Fi3UMaGBctODOJDgA wmJZUVlzuISAsZ56bWTlRWR/wY3nvzN1+Lg6GG0UIpknOLQ75+m70GfYXNELpGYFC8AS yqQ277tg4h5EMWuQK7JDhE0cr2920qpFZBDrRaqtNZXb8gkMqkC4JHtfqnMXU4ES6Eqy J+vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=167YRn++fYV6uBWm30cEoRObvG1upqHih6YB0tP+W1Q=; b=qCNUHbEucONfZ/tp08OCh63NmAw80XY0hRgjN8Xroe54POYg3N0QF0jr0G/f80lCmE ainwhyK56sDq2IXyCCuMAoJ4PkRx/iu2Cl8IoxJhkc9zFU1NKetAjXcK94Pc2Qg67d6k 912s7jFSaHG3v5xVmu+RvssiL31Qt4bntgI0ib7VZiGk8yMnOmGkk/YiZHBvtwQrbibA jgYl2TsWBV9YtLX4mpVvmdu4qzeqV8JSLjJEoRZERfb+oIzrNNxjomsK+RmKDb0lvJyn oxGUmLghaTWhflYFIlQN1TNqgyGzSnHIEz29mIYBB3dZArF0s8QEMX6PWCqeuB/uPjkL riUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LrX9tYB6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g22-20020a1709065d1600b0072b45e10bb0si2606127ejt.922.2022.07.13.07.21.23; Wed, 13 Jul 2022 07:21:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LrX9tYB6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236420AbiGMOH3 (ORCPT + 99 others); Wed, 13 Jul 2022 10:07:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236019AbiGMOHZ (ORCPT ); Wed, 13 Jul 2022 10:07:25 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0A85B32451 for ; Wed, 13 Jul 2022 07:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657721242; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=167YRn++fYV6uBWm30cEoRObvG1upqHih6YB0tP+W1Q=; b=LrX9tYB67amg33LtTG/qPdh8IK+GBZFpvkGnXbJT1a5ZpCUlAtzw8FkkOMZ1/kgIXKaIdF GgVEAvv0uLWzbSQIK2f5P7OZ+tZNQxZ7OEg5pSLEA1cViE/44eRC0dNdU531updDFNTfms Dme5Nh0RovLWn0CYsqXo7R42Rm9banw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-626-wQegNj3LOqyM9K909Bg6aQ-1; Wed, 13 Jul 2022 10:07:19 -0400 X-MC-Unique: wQegNj3LOqyM9K909Bg6aQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6EC223801F5D; Wed, 13 Jul 2022 14:07:18 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 69B361121314; Wed, 13 Jul 2022 14:07:17 +0000 (UTC) From: Ming Lei To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org, Gabriel Krisman Bertazi , ZiyangZhang , Xiaoguang Wang , Ming Lei Subject: [PATCH V5 0/2] ublk: add io_uring based userspace block driver Date: Wed, 13 Jul 2022 22:07:09 +0800 Message-Id: <20220713140711.97356-1-ming.lei@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Guys, ublk driver is one kernel driver for implementing generic userspace block device/driver, which delivers io request from ublk block device(/dev/ublkbN) into ublk server[1] which is the userspace part of ublk for communicating with ublk driver and handling specific io logic by its target module. Another thing ublk driver handles is to copy data between user space buffer and request/bio's pages, or take zero copy if mm is ready for support it in future. ublk driver doesn't handle any IO logic of the specific driver, so it is small/simple, and all io logics are done by the target code in ublkserver. The above two are main jobs done by ublk driver. ublk driver can help to move IO logic into userspace, in which the development work is easier/more effective than doing in kernel, such as, ublk-loop takes < 200 lines of loop specific code to get basically same function with kernel loop block driver, meantime the performance is is even better than kernel loop with same setting. ublksrv[1] provide built-in test for comparing both by running "make test T=loop", for example, see the test result running on VM which is over my lattop(root disk is nvme/device mapper/xfs): [root@ktest-36 ubdsrv]#make -s -C /root/git/ubdsrv/tests run T=loop/001 R=10 running loop/001 fio (ublk/loop(/root/git/ubdsrv/tests/tmp/ublk_loop_VqbMA), libaio, bs 4k, dio, hw queues:1)... randwrite: jobs 1, iops 32572 randread: jobs 1, iops 143052 rw: jobs 1, iops read 29919 write 29964 [root@ktest-36 ubdsrv]# make test T=loop/003 make -s -C /root/git/ubdsrv/tests run T=loop/003 R=10 running loop/003 fio (kernel_loop/kloop(/root/git/ubdsrv/tests/tmp/ublk_loop_ZIVnG), libaio, bs 4k, dio, hw queues:1)... randwrite: jobs 1, iops 27436 randread: jobs 1, iops 95273 rw: jobs 1, iops read 22542 write 22543 Another example is high performance qcow2 support[2], which could be built with ublk framework more easily than doing it inside kernel. Also there are more people who express interests on userspace block driver[3], Gabriel Krisman Bertazi proposes this topic in lsf/mm/ebpf 2022 and mentioned requirement from Google. Ziyang Zhang from Alibaba said they "plan to replace TCMU by UBD as a new choice" because UBD can get better throughput than TCMU even with single queue[4], meantime UBD is simple. Also there is userspace storage service for providing storage to containers. It is io_uring based: io request is delivered to userspace via new added io_uring command which has been proved as very efficient for making nvme passthrough IO to get better IOPS than io_uring(READ/WRITE). Meantime one shared/mmap buffer is used for sharing io descriptor to userspace, the buffer is readonly for userspace, each IO just takes 24bytes so far. It is suggested to use io_uring in userspace(target part of ublk server) to handle IO request too. And it is still easy for ublkserver to support io handling by non-io_uring, and this work isn't done yet, but can be supported easily with help o eventfd. This way is efficient since no extra io command copy is required, no sleep is needed in transferring io command to userspace. Meantime the communication protocol is simple and efficient, one single command of UBD_IO_COMMIT_AND_FETCH_REQ can handle both fetching io request desc and commit command result in one trip. IO handling is often batched after single io_uring_enter() returns, both IO requests from ublk server target and IO commands could be handled as a whole batch. And the patch by patch change can be found in the following tree: https://github.com/ming1/linux/tree/my_for-5.20-ubd-devel_v4 ublk server repo(master branch): https://github.com/ming1/ubdsrv Any comments are welcome! Since V4: - drop patch of "ublk_drv: add UBLK_IO_REFETCH_REQ for supporting to build as module", instead of using io_uring_cmd_complete_in_task for building driver as module - simplify aborting code Since V3: - address Gabriel Krisman Bertazi's comments on V3: add userspace data validation before handling command, remove warning, ... - remove UBLK_IO_COMMIT_REQ command as suggested by Zixiang and Gabriel Krisman Bertazi - fix one request double free when running abort - rewrite/cleanup ublk_copy_pages(), then this handling becomes very clean - add one command of UBLK_IO_REFETCH_REQ for allowing ublk_drv to build as module Since V2: - fix one big performance problem: https://github.com/ming1/linux/commit/3c9fd476951759858cc548dee4cedc074194d0b0 - rename as ublk, as suggested by Gabriel Krisman Bertazi - lots of cleanup & code improvement & bugfix, see details in git hisotry Since V1: Remove RFC now because ublk driver codes gets lots of cleanup, enhancement and bug fixes since V1: - cleanup uapi: remove ublk specific error code, switch to linux error code, remove one command op, remove one field from cmd_desc - add monitor mechanism to handle ubq_daemon being killed, ublksrv[1] includes builtin tests for covering heavy IO with deleting ublk / killing ubq_daemon at the same time, and V2 pass all the two tests(make test T=generic), and the abort/stop mechanism is simple - fix MQ command buffer mmap bug, and now 'xfstetests -g auto' works well on MQ ublk-loop devices(test/scratch) - improve batching submission as suggested by Jens - improve handling for starting device, replace random wait/poll with completion - all kinds of cleanup, bug fix,.. Ming Lei (2): ublk_drv: add io_uring based userspace block driver ublk_drv: support to complete io command via task_work_add drivers/block/Kconfig | 6 + drivers/block/Makefile | 2 + drivers/block/ublk_drv.c | 1589 +++++++++++++++++++++++++++++++++ include/uapi/linux/ublk_cmd.h | 162 ++++ 4 files changed, 1759 insertions(+) create mode 100644 drivers/block/ublk_drv.c create mode 100644 include/uapi/linux/ublk_cmd.h -- 2.31.1