public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Olivier Langlois <[email protected]>,
	Pavel Begunkov <[email protected]>,
	[email protected]
Subject: Re: [PATCH v2 3/3] io_uring/napi: add static napi tracking strategy
Date: Mon, 16 Sep 2024 21:09:17 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <cd6dc57659b7fe0417189b2d019ba7c5a290c34c.1726354973.git.olivier@trillion01.com>

On 9/16/24 1:20 PM, Olivier Langlois wrote:
> add the static napi tracking strategy that allows the user to manually
> manage the napi ids list to busy poll and offload the ring from
> dynamically update the list.

I like this, I suspect for many cases this is all you will need rather
than try and dynamically track multiple instances.

Away for the next week or so, so won't have time to do a proper review
until I'm back. Timing wise this doesn't matter too much as the 6.12
merge window is currently open, hence we cannot target this to anything
sooner than 6.13. So we have time to get this reviewed and queued up.

A few minor comments below.

> diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
> index adc2524fd8e3..10d9030c4242 100644
> --- a/include/uapi/linux/io_uring.h
> +++ b/include/uapi/linux/io_uring.h
> @@ -728,12 +728,40 @@ struct io_uring_buf_status {
>  	__u32	resv[8];
>  };
>  
> +enum io_uring_napi_op {
> +	/* register/ungister backward compatible opcode */
> +	IO_URING_NAPI_REGISTER_OP = 0,
> +
> +	/* opcodes to update napi_list when static tracking is used */
> +	IO_URING_NAPI_STATIC_ADD_ID = 1,
> +	IO_URING_NAPI_STATIC_DEL_ID = 2
> +};
> +
> +enum io_uring_napi_tracking_strategy {
> +	/* value must be 0 for backward compatibility */
> +	IO_URING_NAPI_TRACKING_DYNAMIC = 0,
> +	IO_URING_NAPI_TRACKING_STATIC = 1,
> +	IO_URING_NAPI_TRACKING_INACTIVE = 255
> +};

I think this is a fine way to do it, retaining compatability with what
we have now on the registration side.

>  /* argument for IORING_(UN)REGISTER_NAPI */
>  struct io_uring_napi {
>  	__u32	busy_poll_to;
>  	__u8	prefer_busy_poll;
> -	__u8	pad[3];
> -	__u64	resv;
> +
> +	/* a io_uring_napi_op value */
> +	__u8	opcode;
> +	__u8	pad[2];
> +
> +	/*
> +	 * for IO_URING_NAPI_REGISTER_OP, it is a
> +	 * io_uring_napi_tracking_strategy value.
> +	 *
> +	 * for IO_URING_NAPI_STATIC_ADD_ID/IO_URING_NAPI_STATIC_DEL_ID
> +	 * it is the napi id to add/del from napi_list.
> +	 */
> +	__u32	op_param;
> +	__u32	resv;
>  };

Looks good too.

> +static void common_tracking_show_fdinfo(struct io_ring_ctx *ctx,
> +					struct seq_file *m,
> +					const char *tracking_strategy)
> +{
> +	seq_puts(m, "NAPI:\tenabled\n");
> +	seq_printf(m, "napi tracking:\t%s\n", tracking_strategy);
> +	seq_printf(m, "napi_busy_poll_dt:\t%llu\n", ctx->napi_busy_poll_dt);
> +	if (ctx->napi_prefer_busy_poll)
> +		seq_puts(m, "napi_prefer_busy_poll:\ttrue\n");
> +	else
> +		seq_puts(m, "napi_prefer_busy_poll:\tfalse\n");
> +}
> +
> +static void napi_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
> +{
> +	switch (READ_ONCE(ctx->napi_track_mode)) {
> +	case IO_URING_NAPI_TRACKING_INACTIVE:
> +		seq_puts(m, "NAPI:\tdisabled\n");
> +		break;
> +	case IO_URING_NAPI_TRACKING_DYNAMIC:
> +		common_tracking_show_fdinfo(ctx, m, "dynamic");
> +		break;
> +	case IO_URING_NAPI_TRACKING_STATIC:
> +		common_tracking_show_fdinfo(ctx, m, "static");
> +		break;
> +	}
> +}

Maybe add an "unknown" default entry here, just in case it ever changes
and someone forgets to update the fdinfo code.

> +static inline bool __io_napi_do_busy_loop(struct io_ring_ctx *ctx,
> +					  void *loop_end_arg)
> +{
> +	if (READ_ONCE(ctx->napi_track_mode) == IO_URING_NAPI_TRACKING_STATIC)
> +		return static_tracking_do_busy_loop(ctx, loop_end_arg);
> +	else
> +		return dynamic_tracking_do_busy_loop(ctx, loop_end_arg);
> +}
> +

Minor style nit:

	if (READ_ONCE(ctx->napi_track_mode) == IO_URING_NAPI_TRACKING_STATIC)
		return static_tracking_do_busy_loop(ctx, loop_end_arg);
	return dynamic_tracking_do_busy_loop(ctx, loop_end_arg);

would do.

-- 
Jens Axboe

  reply	other threads:[~2024-09-17  3:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-16 19:19 [PATCH v2 0/3] napi tracking strategy Olivier Langlois
2024-09-16 19:20 ` [PATCH v2 1/3] io_uring/napi: protect concurrent io_napi_entry timeout accesses Olivier Langlois
2024-09-16 19:20 ` [PATCH v2 2/3] io_uring/napi: fix io_napi_entry RCU accesses Olivier Langlois
2024-09-16 19:20 ` [PATCH v2 3/3] io_uring/napi: add static napi tracking strategy Olivier Langlois
2024-09-17  3:09   ` Jens Axboe [this message]
2024-09-17 14:58     ` Olivier Langlois

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