31–40 of 43 posts
Somehow 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 fe…
Earlier quoted context omitted.
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 pr…
The basis of virtio is literally just a ring queue, with its request descriptors looking almost exactly like structs suitable for passing to readv(2) or writev(2); the PCI shim is built on top of that and is completely optional (you can have a purely MMIO virtio device, after all). It was built this way so that KVM would not have to mimic the idiosyncrasies of real hardware: passing data as-is to the physical devices…
// EXAMPLE: virtio_block device taking 512 bytes at 0x1e000, interrupt 42.
virtio_block@1e000 {
compatible = "virtio,mmio";
reg = ;
interrupts = ;
}
My point about PCI isn't strictly about PCI, it applies equally to VirtIO over MMIO. I do not ever want to have my userspace code poke at memory-mapped registers or do interrupt handling just to do the equivalent of an ioctl.
---
OK, fine, maybe PCI and MMIO are irrelevant but there could be opportunities to share struct layouts. In the section describing block devices[1], there's some code listings for the request packets. A representative example is the request struct:
struct virtio_blk_req {
le32 type;
le32 reserved;
le64 sector;
u8 data[][512];
u8 status;
};
Also, just ... just look at the size of the VirtIO specification. There is a lot there. I haven't run a `wc -l` but it would not surprise me if just the spec for VirtIO is longer than the entire patch series for ublk. Out of all that, the sum total of the virtio-blk struct layouts is something like 100, 200 lines.
Is it worth going through the trouble of trying to unify these two unrelated specs just so that we can satisfy some bizarre philosophical goal of carefully avoiding new ideas?
Like, if you're going to go that far, why does virtio-blk need to exist instead of continuing to emulate SCSI? Or using iSCSI for host device transfer? The obvious answer is, again, because different use cases have different requirements. It's silly to cook two soups in the same bowl.
[0] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1...
[1] https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virti...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Earlier quoted context omitted.
It’s obviously proprietary: it’s non-standard and specific to a single vendor. What is the whole idea, though? Serving things to kernel from userland is decades old and commonly used with both NFS and iSCSI. The fact that this particular implementation uses io_uring instead of something non-proprietary like RDMA, is just an implementation detail.
> It’s obviously proprietary: it’s non-standard and specific to a > single vendor. That's not how people typically use "proprietary" when referring to open-source code developed collectively by multiple vendors, universities, and thousands of independent contributors. > What is the whole idea, though? [...] this particular implementation > uses io_uring instead of something non-proprietary like RDMA, is just > an imp…
Indeed, many people believe that source code being available somehow magically makes things non-proprietary. Not sure where that belief came from. An API is proprietary when it 1. Doesn't comply with existing standards, 2. Isn't interoperable, and 3. Is controlled by a single entity.
>multiple vendors
It comes from IBM/RedHat - a single commercial entity, not “thousands of independent contributors”. But yes, if it was a proper community project then it of course wouldn’t be proprietary.
>twice the throughput
Compared to NBD which can’t use RDMA at all. Again: the idea is old and not bad, it’s just that this particular implementation looks like another case of NIH.
Earlier quoted context omitted.
> It’s obviously proprietary: it’s non-standard and specific to a > single vendor. That's not how people typically use "proprietary" when referring to open-source code developed collectively by multiple vendors, universities, and thousands of independent contributors. > What is the whole idea, though? [...] this particular implementation > uses io_uring instead of something non-proprietary like RDMA, is just > an imp…
>That's not how people typically use "proprietary" when referring to open-source code Indeed, many people believe that source code being available somehow magically makes things non-proprietary. Not sure where that belief came from. An API is proprietary when it 1. Doesn't comply with existing standards, 2. Isn't interoperable, and 3. Is controlled by a single entity. >multiple vendors It comes from IBM/RedHat - a si…
For me, the killer use case for this is presenting logical volumes to containers. There just has not been an efficient mechanism for a local storage service in one container to serve logical volumes to another container on the same system until this. For VMs there is virtio/vfio-user, but for containers the highest performing option until this was NVMe-oF/TCP loopback. Basically, you can implement a virtual SAN for c…
Somehow 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 fe…
Quoted post unavailable.
Is anything like this for networking done or in the works?
If I'm understanding ublk and your question correctly, then yes, there are a lot of kernel-bypass networking options out there, such as openonload, dpdk, mellanox (though they seem to have been absorbed into nvidia). You'll likely need a special/particular network card, an external kernel module, and at least an LD_PRELOAD to use them though.
I understand the frustration of having the network driver crash but could it not be run in a way that it doesn't bring down the OS?
It seems to me Java would have a no-brainer advantage of a user-space networking option since you're already in a VM!?
When I saturate my HTTP server the kernel takes 30% of the CPU just copying data for no good reason?!