Re: [PATCH v2] nvme-tcp: pin io_cpu to submitter cpu
Daniel Wagner <[email protected]>
| Newsgroups | org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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?