On 1/27/20 6:29 AM, Pavel Begunkov wrote:
> On 1/26/2020 8:00 PM, Jens Axboe wrote:
>> On 1/26/20 8:11 AM, Pavel Begunkov wrote:
>>> On 1/26/2020 4:51 AM, Daurnimator wrote:
>>>> On Fri, 24 Jan 2020 at 10:16, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>>>
>>>> I don't love the idea of some new type of magic user<>kernel
>>>> identifier. It would be nice if the id itself was e.g. a file
>>>> descriptor
>>>>
>>>> What if when creating an io_uring you could pass in an existing
>>>> io_uring file descriptor, and the new one would share the io-wq
>>>> backend?
>>>>
>>> Good idea! It can solve potential problems with jails, isolation, etc in
>>> the future.
>>>
>>> May we need having other shared resources and want fine-grained control
>>> over them at some moment? It can prove helpful for the BPF plans.
>>> E.g.
>>>
>>> io_uring_setup(share_io-wq=ring_fd1,
>>> share_fds=ring_fd2,
>>> share_ebpf=ring_fd3, ...);
>>>
>>> If so, it's better to have more flexible API. E.g. as follows or a
>>> pointer to a struct with @size field.
>>>
>>> struct io_shared_resource {
>>> int type;
>>> int fd;
>>> };
>>>
>>> struct io_uring_params {
>>> ...
>>> struct io_shared_resource shared[];
>>> };
>>>
>>> params = {
>>> ...
>>> .shared = {{ATTACH_IO_WQ, fd1}, ..., SANTINEL_ENTRY};
>>> };
>>
>> I'm fine with changing/extending the sharing API, please send a
>> patch!
>>
>
> Ok. I can't promise it'll play handy for sharing. Though, you'll be out
> of space in struct io_uring_params soon anyway.
I'm going to keep what we have for now, as I'm really not imagining a
lot more sharing - what else would we share? So let's not over-design
anything.
--
Jens Axboe
