Lines Matching refs:IO
28 ublk block device (``/dev/ublkb*``) is added by ublk driver. Any IO request
37 After the IO is handled by userspace, the result is committed back to the
38 driver, thus completing the request cycle. This way, any specific IO handling
39 logic is totally done by userspace, such as loop's IO handling, NBD's IO
40 communication, or qcow2's IO mapping.
44 IO too, which is 1:1 mapped with IO of ``/dev/ublkb*``.
46 Both the IO request forward and IO handling result committing are done via
49 give better IOPS than block IO; which is why ublk is one of high performance
50 implementation of userspace block device: not only IO request communication is
51 done by io_uring, but also the preferred IO handling in ublk server is io_uring
103 WRT IO command communication. Basic device info is sent together with this
105 such as ``nr_hw_queues``, ``queue_depth``, and max IO request buffer size,
112 related, or request queue limit related, but can't be IO logic specific,
113 because the driver does not handle any IO logic. This command has to be
119 pthread & io_uring for handling ublk IO), this command is sent to the
125 Halt IO on ``/dev/ublkb*`` and remove the device. When this command returns,
139 set up the per-queue context efficiently, such as bind affine CPUs with IO
140 pthread and try to allocate buffers in IO thread context.
145 responsibility to save IO target specific info in userspace.
232 ublk server needs to create per-queue IO pthread & io_uring for handling IO
233 commands via io_uring passthrough. The per-queue IO pthread
234 focuses on IO handling and shouldn't handle any control & management
237 The's IO is assigned by a unique tag, which is 1:1 mapping with IO
240 UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
242 exporting IO info to the server; such as IO offset, length, OP/flags and
244 and IO tag directly.
246 The following IO commands are communicated via io_uring passthrough command,
247 and each command is only for forwarding the IO and committing the result
248 with specified IO tag in the command data:
252 Sent from the server IO pthread for fetching future incoming IO requests
254 IO pthread for ublk driver to setup IO forward environment.
258 When an IO request is destined to ``/dev/ublkb*``, the driver stores
259 the IO's ``ublksrv_io_desc`` to the specified mapped area; then the
260 previous received IO command of this IO tag (either ``UBLK_IO_FETCH_REQ``
262 the IO notification via io_uring.
264 After the server handles the IO, its result is committed back to the
268 requests with the same IO tag. That is, ``UBLK_IO_COMMIT_AND_FETCH_REQ``
269 is reused for both fetching request and committing back IO result.
274 issued to ublk server without data copy. Then, IO backend of ublk server
283 should not enable UBLK_F_NEED_GET_DATA. ublk server pre-allocates IO
284 buffer for each IO by default. Any new project should try to use this
290 - data copy between ublk server IO buffer and ublk block IO request
292 The driver needs to copy the block IO request pages into the server buffer
293 (pages) first for WRITE before notifying the server of the coming IO, so
298 the server buffer (pages) read to the IO request pages.
309 occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that
310 big requests (IO size >= 256 KB) may benefit a lot from zero copy.