netdev - Re: [RFC PATCH v4 09/27] nvme-fabrics: Move NVMF_ALLOWED_OPTS and NVMF_REQUIRED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 May 2021 18:50:50 +0300
From:   Shai Malin <malin1024@...il.com>
To:     Hannes Reinecke <hare@...e.de>, linux-nvme@...ts.infradead.org
Cc:     Shai Malin <smalin@...vell.com>, netdev@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org, sagi@...mberg.me, hch@....de,
        axboe@...com, kbusch@...nel.org, Ariel Elior <aelior@...vell.com>,
        Michal Kalderon <mkalderon@...vell.com>, okulkarni@...vell.com,
        pkushwaha@...vell.com, Arie Gershberg <agershberg@...vell.com>
Subject: Re: [RFC PATCH v4 09/27] nvme-fabrics: Move NVMF_ALLOWED_OPTS and
 NVMF_REQUIRED_OPTS definitions

On 4/29/21 3:19 PM, Hannes Reinecke wrote:
> On 4/29/21 9:09 PM, Shai Malin wrote:
> > From: Arie Gershberg <agershberg@...vell.com>
> >
> > Move NVMF_ALLOWED_OPTS and NVMF_REQUIRED_OPTS definitions
> > to header file, so it can be used by transport modules.
> >
> > Acked-by: Igor Russkikh <irusskikh@...vell.com>
> > Signed-off-by: Arie Gershberg <agershberg@...vell.com>
> > Signed-off-by: Prabhakar Kushwaha <pkushwaha@...vell.com>
> > Signed-off-by: Omkar Kulkarni <okulkarni@...vell.com>
> > Signed-off-by: Michal Kalderon <mkalderon@...vell.com>
> > Signed-off-by: Ariel Elior <aelior@...vell.com>
> > Signed-off-by: Shai Malin <smalin@...vell.com>
> > ---
> >   drivers/nvme/host/fabrics.c | 7 -------
> >   drivers/nvme/host/fabrics.h | 7 +++++++
> >   2 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> > index 604ab0e5a2ad..55d7125c8483 100644
> > --- a/drivers/nvme/host/fabrics.c
> > +++ b/drivers/nvme/host/fabrics.c
> > @@ -1001,13 +1001,6 @@ void nvmf_free_options(struct nvmf_ctrl_options *opts)
> >   }
> >   EXPORT_SYMBOL_GPL(nvmf_free_options);
> >
> > -#define NVMF_REQUIRED_OPTS   (NVMF_OPT_TRANSPORT | NVMF_OPT_NQN)
> > -#define NVMF_ALLOWED_OPTS    (NVMF_OPT_QUEUE_SIZE | NVMF_OPT_NR_IO_QUEUES | \
> > -                              NVMF_OPT_KATO | NVMF_OPT_HOSTNQN | \
> > -                              NVMF_OPT_HOST_ID | NVMF_OPT_DUP_CONNECT |\
> > -                              NVMF_OPT_DISABLE_SQFLOW |\
> > -                              NVMF_OPT_FAIL_FAST_TMO)
> > -
> >   static struct nvme_ctrl *
> >   nvmf_create_ctrl(struct device *dev, const char *buf)
> >   {
> > diff --git a/drivers/nvme/host/fabrics.h b/drivers/nvme/host/fabrics.h
> > index 888b108d87a4..b7627e8dcaaf 100644
> > --- a/drivers/nvme/host/fabrics.h
> > +++ b/drivers/nvme/host/fabrics.h
> > @@ -68,6 +68,13 @@ enum {
> >       NVMF_OPT_FAIL_FAST_TMO  = 1 << 20,
> >   };
> >
> > +#define NVMF_REQUIRED_OPTS   (NVMF_OPT_TRANSPORT | NVMF_OPT_NQN)
> > +#define NVMF_ALLOWED_OPTS    (NVMF_OPT_QUEUE_SIZE | NVMF_OPT_NR_IO_QUEUES | \
> > +                              NVMF_OPT_KATO | NVMF_OPT_HOSTNQN | \
> > +                              NVMF_OPT_HOST_ID | NVMF_OPT_DUP_CONNECT |\
> > +                              NVMF_OPT_DISABLE_SQFLOW |\
> > +                              NVMF_OPT_FAIL_FAST_TMO)
> > +
> >   /**
> >    * struct nvmf_ctrl_options - Used to hold the options specified
> >    *                        with the parsing opts enum.
> >
>
> Why do you need them? None of the other transport drivers use them, why you?
>

Different HW devices that are offloading the NVMeTCP might have different
limitations of the allowed options.
For example, a device that does not support all the queue types.
With tcp and rdma, only the nvme-tcp and nvme-rdma layers handle those
attributes and the HW devices do not create any limitations for the allowed
options.

An alternative design could be to add separate fields in nvme_tcp_ofld_ops such
as max_hw_sectors and max_segments that we already have in this series.

Which would you prefer?

> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                Kernel Storage Architect
> hare@...e.de                              +49 911 74053 688
> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer