public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <keith.busch@wdc.com>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH] nvme-multipath: add an 'ana_groups_only' module option
Date: Mon, 7 Feb 2022 14:00:53 +0100	[thread overview]
Message-ID: <285e28aa-4297-4f29-e8c4-25f8222b85a2@suse.de> (raw)
In-Reply-To: <93fb8e2d-3edc-0753-f71a-34c7ce054c27@grimberg.me>

On 2/7/22 13:37, Sagi Grimberg wrote:
> 
>> On large installations the ANA log buffer can be exceedingly large;
>> we've come across a controller with 49 ANA Group Descriptors and
>> 65536 namespaces, resulting in an ANA buffer with an order-7 allocation.
>> And this is just to validate that the namespace ID is _really_listed
>> in the log page.
>> So to avoid an overly large memory allocation we can leverage the
>> 'RGO' bit when retrieving the ANA log page, and check whether the
>> ANA group ID from the namespace is found in the ANA descriptors.
>> That cuts down the memory allocation, and provides the same result.
>> But to be on the safe side I've added a module option 'ana_groups_only'
>> to switch between modes.
> 
> Hannes, why not a sysfs writable attribute? One can add a udev rule if
> it wants a one-shot all controllers...
> 
'tis a bit late, innit?
By the time we manage to write to the sysfs attribute (which, out of 
necessity, will be a controller attribute) the controller is already 
present, and the ANA log will already be read ...

> Although maybe that will bring us to yet another attribute that is
> unstable until the controller identifies...
> 
Yep.

> I think we are getting more indication that the controller device
> creation is sitting in the wrong place...

As mentioned earlier: main problem is that we need the controller device 
to initiate a controller removal. And as there is a possibility that the 
device initialisation _itself_ goes wrong we might need to tear down the
controller even before initialisation is done.
Which currently requires the sysfs attribute.
If we manage to figure out how to do that without the sysfs attribute
we should be fine.

Not that it'll help us in this case, though.
The only way out of _this_ issue is to pass in the configuration for
controller setup, ie adding a new argument to the fabrics configuration 
(eg 'ana_groups_only=1' or somesuch).
But I'm not sure if we want to go that way ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer


  reply	other threads:[~2022-02-07 13:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 10:00 [PATCH] nvme-multipath: add an 'ana_groups_only' module option Hannes Reinecke
2022-02-07 12:37 ` Sagi Grimberg
2022-02-07 13:00   ` Hannes Reinecke [this message]
2022-02-09  8:07 ` Christoph Hellwig
2022-02-09  8:49   ` Hannes Reinecke
2022-02-09 13:57     ` Christoph Hellwig
2022-02-10  2:52   ` John Meneghini
2022-02-10  5:43     ` Christoph Hellwig
2022-02-10  8:17     ` Hannes Reinecke

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=285e28aa-4297-4f29-e8c4-25f8222b85a2@suse.de \
    --to=hare@suse.de \
    --cc=hch@lst.de \
    --cc=keith.busch@wdc.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox