Hannes Reinecke <hare@xxxxxxx> writes: > Actually, I'd rather have something like an 'inverse io_uring', where an > application creates a memory region separated into several 'ring' for > submission and completion. > Then the kernel could write/map the incoming data onto the rings, and > application can read from there. > Maybe it'll be worthwhile to look at virtio here. > > But in either case, using fds or pipes for commands doesn't really > scale, as the number of fds is inherently limited. And using fds > restricts you to serial processing (as you can read only sequentially > from a fd); with mmap() you'll get a greater flexibility and the option > of parallel processing. Hannes, I'm not trying to push an fd implementation, and seems clear that io_uring is the right way to go. But isn't fd virtually unlimited, as they can be extended up to procfs's file-max for a specific user? Also, I was proposing one fd per IO operation, so each request data is independent. But, even within each IO, it doesn't necessarily need to be sequential. Isn't pread/pwrite parallel on the same fd? A FD-based implementation could also use existing io_uring operations, IORING_OP_READV/IORING_OP_WRITEV, against the file descriptor. -- Gabriel Krisman Bertazi
