public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Subject: Re: [PATCH 2/2] io_uring: add timeout update
Date: Mon, 30 Nov 2020 11:40:25 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 11/30/20 11:27 AM, Pavel Begunkov wrote:
> On 30/11/2020 18:15, Jens Axboe wrote:
>> On 11/29/20 10:12 AM, Pavel Begunkov wrote:
>>> +	tr->flags = READ_ONCE(sqe->timeout_flags);
>>> +	if (tr->flags) {
>>> +		if (!(tr->flags & IORING_TIMEOUT_UPDATE))
>>> +			return -EINVAL;
>>> +		if (tr->flags & ~(IORING_TIMEOUT_UPDATE|IORING_TIMEOUT_ABS))
>>> +			return -EINVAL;
>>
>> These flag comparisons are a bit obtuse - perhaps warrants a comment?
> 
> Ok, the one below should be more readable.
> 
> if (tr->flags & IORING_TIMEOUT_UPDATE) {
> 	if (flags & ~ALLOWED_UPDATE_FLAGS)
> 		return -EINVAL;
> 	...
> } else if (tr->flags) {
> 	/* timeout removal doesn't support flags */
> 	return -EINVAL;
> }

Yeah, that's actually readable.

>>> +		ret = __io_sq_thread_acquire_mm(req->ctx);
>>> +		if (ret)
>>> +			return ret;
>>
>> Why is this done manually?
> 
> mm is only needed in *prep(), so don't want IO_WQ_WORK_MM to put it
> into req->work since it also affects timeout remove reqs.

Don't think it's worth it, I'd just mark it needing it uncondtionally
instead. Reason being the obvious of not having stuff like this buried
deep in an op hander, but also that for non SQPOLL, we'll do these
inline always and it's a no-op. For SQPOLL we'd need to grab it, but
I'd rather pay that cost than have this in there.

>>> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>>> index 6bb8229de892..12a6443ea60d 100644
>>> --- a/include/uapi/linux/io_uring.h
>>> +++ b/include/uapi/linux/io_uring.h
>>> @@ -151,6 +151,7 @@ enum {
>>>   * sqe->timeout_flags
>>>   */
>>>  #define IORING_TIMEOUT_ABS	(1U << 0)
>>> +#define IORING_TIMEOUT_UPDATE	(1U << 31)
>>
>> Why bit 31?
> 
> Left bits for other potential timeout modes, don't know which though.
> Can return it to bit 1.

Let's just use 1, there's no clear separation in there anyway.

-- 
Jens Axboe


      reply	other threads:[~2020-11-30 18:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-29 17:12 [PATCH 0/2] implement timeout update Pavel Begunkov
2020-11-29 17:12 ` [PATCH 1/2] io_uring: restructure io_timeout_cancel() Pavel Begunkov
2020-11-29 17:12 ` [PATCH 2/2] io_uring: add timeout update Pavel Begunkov
2020-11-30 18:15   ` Jens Axboe
2020-11-30 18:27     ` Pavel Begunkov
2020-11-30 18:40       ` Jens Axboe [this message]

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] \
    /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