On 10/3/24 11:50, Miklos Szeredi wrote:
> On Wed, 2 Oct 2024 at 23:54, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
>>
>> Hi Miklos,
>>
>> in the discussion we had you asked to avoid an entry tag/index,
>> in the mean time I don't think we can.
>> In fuse_uring_cmd(), i.e. the function that gets
>> 'struct io_uring_cmd *cmd' we need identify the corresponding fuse
>> data structure ('struct fuse_ring_ent'). Basically same as in
>> as in do_write(), which calls request_find() and does a list search.
>> With a large queue size that would be an issue (and even for smaller
>> queue sizes not beautiful, imho).
>
> I don't really understand the problem.
>
> Is efficiency the issue? I agree, that that would need to be
> addressed. But that's not a interface question, it's an
> implementation question, and there are plenty of potential solutions
> for that (hash table, rbtree, etc.)
>
>> I'm now rewriting code to create an index in
>> FUSE_URING_REQ_FETCH and return that later on with the request
>> to userspace. That needs to do realloc the array as we do know the
>> exact queue size anymore.
>
> It should not be an array because dynamic arrays are complex and
> inefficient. Rbtree sounds right, but I haven't thought much about
> it.
What I mean is that you wanted to get rid of the 'tag' - using any kind of
search means we still need it. I.e. we cannot just take last list head
or tail and use that.
The array is only dynamic at initialization time. And why spending O(logN)
to search instead of O(1)?
And I know that it is an implementation detail, I just would like to avoid
many rebasing rounds on these details.
Thanks,
Bernd
