All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sungup Moon <sungup.moon@samsung.com>
To: "hch@lst.de" <hch@lst.de>
Cc: "kbusch@kernel.org" <kbusch@kernel.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE:(2) [PATCH] driver/nvme/host: Support duplicated nsid for the private
Date: Mon, 14 Mar 2022 18:17:55 +0900	[thread overview]
Message-ID: <20220314091755epcms2p1c638716a47c2eae1a6069e2b73e5dc5d@epcms2p1> (raw)
In-Reply-To: <20220314070808.GB3806@lst.de>

Thank you for your reply,

>  
> On Mon, Mar 14, 2022 at 04:05:05PM +0900, Sungup Moon wrote:
> > When the multi-controller, managed by a special admin command, has private
> > namespace with same nsid, current linux driver raise "Duplicate unshared
> > namespace" error. But, NVMe Specification defines the NSID usage like this:
> > 
> > If Namespace Management, ANA Reporting, or NVM Sets are supported, the
> > NSIDs shall be unique within the NVM subsystem. If the Namespace
> > Management, ANA Reporting, and NVM Sets are not supported, then NSIDs:
> > a) for shared namespace shall be unique; and
> > b) for private namespace are not required to be unique.
> > (reference: 6.1.6 NSID and Namespace Usage; NVM Express 1.4c spec)
> > 
> > So, if a multi-controller, which is not managed by Namespace Management
> > function, creates some private namespaces without ANA and NVM Sets, the
> > duplicated NSID should be allowed because that is not a NVMe specification
> > violation.
> > 
> > But, current nvme driver checks only namespace is shared or not, so I
> > propose following patch:
> > 1. nvme_ctrl has unique_nsid field to identify that controller should
> >    assign unique nsid.
> > 2. nvme_init_ns_head function creates new nvme_ns_head instance not only
> >    head is null but controller's unique_nsid is false (no flagged
> >    attribute) and namespace is not shared.
> > 3. for creating bdev device file, nvme_mpath_set_disk_name will return
> >    false when unique_nsid is false and namespace is not shared.
> > 4. also, nvme_mpath_alloc_disk alto return 0 with same manner.
>  
> From a very quick glance this looks good.  But please make sure you don't
> spill over 80 charactes per line.

I checked changes using "scripts/checkpatch.pl --terse --file {changed file}",
but there is no warning on my changes. However I will recheck the spill-over
lines over 80 characters.

> Also I think instead of adding the
> unique_nsid field a little helper that checks the relevant flags might
> be a lіttle nicer.  It is not checked in a fast path anywere and the
> checks are pretty trivial.
> 

Thank you for your advise! I will remove flag and add checking function for
unique nsid.

Thank you,
Sungup Moon

      parent reply	other threads:[~2022-03-14  9:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220314070505epcms2p26dff1d529f4d8c208728e5fa5c5dd928@epcms2p2>
2022-03-14  7:05 ` [PATCH] driver/nvme/host: Support duplicated nsid for the private Sungup Moon
2022-03-14  7:08   ` hch
     [not found]   ` <CGME20220314070505epcms2p26dff1d529f4d8c208728e5fa5c5dd928@epcms2p1>
2022-03-14  9:17     ` Sungup Moon [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 \
    --in-reply-to=20220314091755epcms2p1c638716a47c2eae1a6069e2b73e5dc5d@epcms2p1 \
    --to=sungup.moon@samsung.com \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.