An io_uring-based user-space block driver
1–10 of 43 posts
Re: An io_uring-based user-space block driver
#2Is anything like this for networking done or in the works?
Re: An io_uring-based user-space block driver
#3Somehow this reminded me of this post on LKLM:
- .x.x: Linus went crazy, broke absolutely _everything_, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two").
[*] https://lkml.org/lkml/2005/3/2/247
It's really interesting to see Linux getting more and more micro-kernel like features throughout the years.
Re: An io_uring-based user-space block driver
#4Is anything like this for networking done or in the works?
For networking the closest equivalent would be TUN/TAP, which lets userspace route either IP packets (TUN) or Ethernet frames (TAP).
Re: An io_uring-based user-space block driver
#5Is anything like this for networking done or in the works?
[deleted]
Re: An io_uring-based user-space block driver
#6Is anything like this for networking done or in the works?
There is XDP.
Re: An io_uring-based user-space block driver
#7I wonder if this could replace most uses of NBD (network block devices), and/or help get iSCSI into userspace where more flexible load-balancing policy can be implemented.
It also reminds me of attempts to define BUSE[0][1][2], which would have been a block device equivalent of FUSE. IIRC attempts to get BUSE into the Linux kernel have been blocked for performance reasons -- the FUSE protocol isn't well designed and is only barely acceptable for VFS.
If io_uring (+ careful use of zero-copy) has fixed the performance issues with userspace block devices, maybe it would be applicable to FUSE (or FUSE-v2)? I've tried using io_uring with the current FUSE protocol to reduce syscall overhead and it kinda works, but a protocol designed to operate in that mode from the beginning would be even better.
[0] https://github.com/acozzette/BUSE
[1] https://dspace.cuni.cz/bitstream/handle/20.500.11956/148791/...
Re: An io_uring-based user-space block driver
#8That reminds me quite strongly of VirtIO (block) devices... and yet the actual command format is, of course, different. Why can't we stop re-inveting things over and over?
Re: An io_uring-based user-space block driver
#9So it’s essentially like userspace iSCSI server, but proprietary?
Re: An io_uring-based user-space block driver
#10That reminds me quite strongly of VirtIO (block) devices... and yet the actual command format is, of course, different. Why can't we stop re-inveting things over and over?
Because different use cases require different designs? If you try to create a protocol that can work for all purposes, it'll be a poor fit for any of them and will be out-competed by more specialized alternatives.
There's a reason emulators design their virtual devices to resemble real hardware (PCI, SCSI, USB) -- there's already going to be a bunch of code in the hypervisor to create fake hardware. It's also more practical to piggy-back on PCI (etc) when the spec needs to be implemented by competing vendors, since there's no kernel and no OS idioms involved. Not to mention various pre-kernel code such as EFI and bootloaders.
Conversely, userspace developers really do not want to be coding up a fake PCI device with registers and interrupts and so on just to get some bytes into the kernel. They want to invoke system calls (ioctl, mmap, io_uring) and let the OS handle the details.