Re: [PATCH v2] nvme-tcp: pin io_cpu to submitter cpu

[Daniel Wagner]

On Thu, Aug 20, 2026 at 01:36:34AM -0700, Saravanan D wrote:
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index fd5abd04e080..26f8703744de 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -695,6 +695,7 @@ static const match_table_t opt_tokens = {
>  	{ NVMF_OPT_NR_WRITE_QUEUES,	"nr_write_queues=%d"	},
>  	{ NVMF_OPT_NR_POLL_QUEUES,	"nr_poll_queues=%d"	},
>  	{ NVMF_OPT_TOS,			"tos=%d"		},
> +	{ NVMF_OPT_IO_CPU_ADOPT,	"io_cpu_adopt"		},
>  #ifdef CONFIG_NVME_TCP_TLS
>  	{ NVMF_OPT_KEYRING,		"keyring=%d"		},
>  	{ NVMF_OPT_TLS_KEY,		"tls_key=%d"		},
> @@ -951,6 +952,9 @@ static int nvmf_parse_options(struct nvmf_ctrl_options *opts,
>  		case NVMF_OPT_DATA_DIGEST:
>  			opts->data_digest = true;
>  			break;
> +		case NVMF_OPT_IO_CPU_ADOPT:
> +			opts->io_cpu_adopt = true;
> +			break;

FWIW, from past experience if this gets accepted, it is most likely not
the last policy controlling knob which is needed. I see this somewhat
orthogonal to io_policy options. Thus my question should this user
interface be just a bool or should we have something more future proof
here?