Re: [LSF/MM/BPF TOPIC] block drivers in user space

From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Hannes Reinecke <hare@suse.de>
Cc: lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] block drivers in user space
Date: Wed, 02 Mar 2022 18:04:08 -0500	[thread overview]
Message-ID: <87tucgj6s7.fsf@collabora.com> (raw)
In-Reply-To: <986caf55-65d1-0755-383b-73834ec04967@suse.de> (Hannes Reinecke's message of "Tue, 22 Feb 2022 07:57:27 +0100")

Hannes Reinecke <hare@suse.de> 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