From: Bernd Schubert <[email protected]>
To: Miklos Szeredi <[email protected]>
Cc: Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
[email protected], [email protected],
Joanne Koong <[email protected]>,
Josef Bacik <[email protected]>,
Amir Goldstein <[email protected]>,
Ming Lei <[email protected]>, David Wei <[email protected]>,
[email protected]
Subject: Re: [PATCH RFC v6 06/16] fuse: {uring} Handle SQEs - register commands
Date: Sat, 23 Nov 2024 13:42:20 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJfpegtih77CpuSQAOkUaKRMPj44ua65+_MUMa3LqgYjLFofqg@mail.gmail.com>
On 11/23/24 10:52, Miklos Szeredi wrote:
> On Fri, 22 Nov 2024 at 00:44, Bernd Schubert <[email protected]> wrote:
>
>> +static struct fuse_ring *fuse_uring_create(struct fuse_conn *fc)
>> +{
>> + struct fuse_ring *ring = NULL;
>> + size_t nr_queues = num_possible_cpus();
>> + struct fuse_ring *res = NULL;
>> +
>> + ring = kzalloc(sizeof(*fc->ring) +
>> + nr_queues * sizeof(struct fuse_ring_queue),
>
> Left over from a previous version?
Why? This struct holds all the queues? We could also put into fc, but
it would take additional memory, even if uring is not used.
>
>> +static void fuse_uring_ent_avail(struct fuse_ring_ent *ring_ent,
>> + struct fuse_ring_queue *queue)
>> + __must_hold(&queue->lock)
>> +{
>> + struct fuse_ring *ring = queue->ring;
>> +
>> + lockdep_assert_held(&queue->lock);
>> +
>> + /* unsets all previous flags - basically resets */
>> + pr_devel("%s ring=%p qid=%d state=%d\n", __func__, ring,
>> + ring_ent->queue->qid, ring_ent->state);
>> +
>> + if (WARN_ON(ring_ent->state != FRRS_COMMIT)) {
>> + pr_warn("%s qid=%d state=%d\n", __func__, ring_ent->queue->qid,
>> + ring_ent->state);
>> + return;
>> + }
>> +
>> + list_move(&ring_ent->list, &queue->ent_avail_queue);
>> +
>> + ring_ent->state = FRRS_WAIT;
>> +}
>
> AFAICS this function is essentially just one line, the rest is
> debugging. While it's good for initial development it's bad for
> review because the of the bad signal to noise ratio (the debugging
> part is irrelevant for code review).
>
> Would it make sense to post the non-RFC version without most of the
> pr_debug()/pr_warn() stuff and just keep the simple WARN_ON() lines
> that signal if something has gone wrong.
I can remove the pr_debug/pr_warn lines for the non-RFC version, that
will come early next week.
>
> Long term we could get rid of some of that too. E.g ring_ent->state
> seems to be there just for debugging, but if the code is clean enough
> we don't need to have a separate state.
Almost, please see
[PATCH RFC v6 15/16] fuse: {io-uring} Prevent mount point hang on fuse-server termination
there you really need a ring state, because access is outside of lists.
Unless you want to iterate over the lists, if the the entry is still
in there. Please see the discussion with Joanne in RFC v5.
I have also added in v6 15/16 comments about non-list access.
>
>> +#if 0
>> + /* Does not work as sending over io-uring is async */
>> + err = -ETXTBSY;
>> + if (fc->initialized) {
>> + pr_info_ratelimited(
>> + "Received FUSE_URING_REQ_FETCH after connection is initialized\n");
>> + return err;
>> + }
>> +#endif
>
> I fail to remember what's up with this. Why is it important that
> FETCH is sent before INIT reply?
That is basically what I try to explain with the comment,
it does not work. I had left it in the code, so that you would
run over it, looks like that worked :)
Even though libfuse sends the SQEs before
setting up /dev/fuse threads, handling the SQEs takes longer.
So what happens is that while IORING_OP_URING_CMD/FUSE_URING_REQ_FETCH
are coming in, FUSE_INIT reply gets through. In userspace we do not
know at all, when these SQEs are registered, because we don't get
a reply. Even worse, we don't even know if io-uring works at all and
cannot adjust number of /dev/fuse handling threads. Here setup with
ioctls had a clear advantage - there was a clear reply.
The other issue is, that we will probably first need handle FUSE_INIT
in userspace before sending SQEs at all, in order to know the payload
buffer size.
>
>> diff --git a/fs/fuse/fuse_dev_i.h b/fs/fuse/fuse_dev_i.h
>> index 6c506f040d5fb57dae746880c657a95637ac50ce..e82cbf9c569af4f271ba0456cb49e0a5116bf36b 100644
>> --- a/fs/fuse/fuse_dev_i.h
>> +++ b/fs/fuse/fuse_dev_i.h
>> @@ -8,6 +8,7 @@
>>
>> #include <linux/types.h>
>>
>> +
>
> Unneeded extra line.
Yeah, I didn't review these patches on my own yet, there are probably
more tiny things like that all over the place - will be done by next
with in the non-RFC version.
Thanks,
Bernd
next prev parent reply other threads:[~2024-11-23 12:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 23:43 [PATCH RFC v6 00/16] fuse: fuse-over-io-uring Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 01/16] fuse: rename to fuse_dev_end_requests and make non-static Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 02/16] fuse: Move fuse_get_dev to header file Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 03/16] fuse: Move request bits Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 04/16] fuse: Add fuse-io-uring design documentation Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 05/16] fuse: make args->in_args[0] to be always the header Bernd Schubert
2024-11-23 9:01 ` Miklos Szeredi
2024-11-21 23:43 ` [PATCH RFC v6 06/16] fuse: {uring} Handle SQEs - register commands Bernd Schubert
2024-11-23 9:52 ` Miklos Szeredi
2024-11-23 12:42 ` Bernd Schubert [this message]
2024-11-23 13:09 ` Miklos Szeredi
2024-11-21 23:43 ` [PATCH RFC v6 07/16] fuse: Make fuse_copy non static Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 08/16] fuse: Add fuse-io-uring handling into fuse_copy Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 09/16] fuse: {uring} Add uring sqe commit and fetch support Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 10/16] fuse: {uring} Handle teardown of ring entries Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 11/16] fuse: {uring} Allow to queue fg requests through io-uring Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 12/16] fuse: {uring} Allow to queue to the ring Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 13/16] io_uring/cmd: let cmds to know about dying task Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 14/16] fuse: {uring} Handle IO_URING_F_TASK_DEAD Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 15/16] fuse: {io-uring} Prevent mount point hang on fuse-server termination Bernd Schubert
2024-11-21 23:43 ` [PATCH RFC v6 16/16] fuse: enable fuse-over-io-uring Bernd Schubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox