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.
186 ublk server needs to create per-queue IO pthread & io_uring for handling IO
187 commands via io_uring passthrough. The per-queue IO pthread
188 focuses on IO handling and shouldn't handle any control & management
191 The's IO is assigned by a unique tag, which is 1:1 mapping with IO
194 UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
196 exporting IO info to the server; such as IO offset, length, OP/flags and
198 and IO tag directly.
200 The following IO commands are communicated via io_uring passthrough command,
201 and each command is only for forwarding the IO and committing the result
202 with specified IO tag in the command data:
206 Sent from the server IO pthread for fetching future incoming IO requests
208 IO pthread for ublk driver to setup IO forward environment.
212 When an IO request is destined to ``/dev/ublkb*``, the driver stores
213 the IO's ``ublksrv_io_desc`` to the specified mapped area; then the
214 previous received IO command of this IO tag (either ``UBLK_IO_FETCH_REQ``
216 the IO notification via io_uring.
218 After the server handles the IO, its result is committed back to the
222 requests with the same IO tag. That is, ``UBLK_IO_COMMIT_AND_FETCH_REQ``
223 is reused for both fetching request and committing back IO result.
228 issued to ublk server without data copy. Then, IO backend of ublk server
237 should not enable UBLK_F_NEED_GET_DATA. ublk server pre-allocates IO
238 buffer for each IO by default. Any new project should try to use this
244 - data copy between ublk server IO buffer and ublk block IO request
246 The driver needs to copy the block IO request pages into the server buffer
247 (pages) first for WRITE before notifying the server of the coming IO, so
252 the server buffer (pages) read to the IO request pages.
260 ublk driver doesn't handle any IO logic. Its function is well defined
272 occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that
273 big requests (IO size >= 256 KB) may benefit a lot from zero copy.