From: Martin Wilck <mwilck@suse.com>
To: Sagi Grimberg <sagi@grimberg.me>, Keith Busch <kbusch@kernel.org>,
linux-nvme@lists.infradead.org
Cc: Hannes Reinecke <hare@suse.de>,
Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Subject: Re: [PATCH 35/35] monitor: add option --keep/-K
Date: Fri, 29 Jan 2021 22:15:42 +0100 [thread overview]
Message-ID: <c00de29ef02bf39ae231a2816f03c8e920ebdc29.camel@suse.com> (raw)
In-Reply-To: <552cb65a-8f1b-e414-4de8-f53ff469e8a1@grimberg.me>
On Fri, 2021-01-29 at 13:11 -0800, Sagi Grimberg wrote:
>
> > > > If it does, it will recreate discovery controllers for every
> > > > host_traddr/traddr/trsvcid tuple it finds. "--keep" semantics
> > > > are
> > > > only
> > > > necessary for addresses on which no regular (non-discovery)
> > > > connection
> > > > exists.
> > >
> > > Wait, Maybe I'm missing something here, but are you saying that
> > > for
> > > every traddr/trsvcid it finds (both nvm and discovery) it will
> > > attempt
> > > to connect a discovery controller?
> > >
> > > If so, this is absolutely wrong.
> >
> > Currently, it tries to do that on startup, if (and only if) the
> > --startup option is given. My expectation was that the connection
> > attempts would simply fail if there was no discovery subsystem to
> > connect to. Anyway, it's not the default behavior, and can be
> > dropped
> > completely if it's so bad that we shouldn't ever attempt to do it.
>
> IMO it needs to be dropped. I didn't understand this at first because
> it never even occurred to me that such an assumption can be even
> made.
>
> > If the service is started early on during boot, and event-based
> > discovery works (i.e. we also have the mDNS part in place), this
> > won't
> > be necessary of course.
>
> This isn't necessary regardless. At best the discovery controller
> endpoints should be obtained from discovery.conf or equivalent.
Understood.
> I don't even see how does this help in early boot anyways, how
> do the existing controllers get connected?
For FC, it works today. You can start the monitor in the initrd, it
will receive the fc_udev_device events, and autoconnect (just like
traditional udev/systemd based discovery). For other transports, it'd
be more work, as we'd need to do mDNS discovery from an initrd
environment. I wouldn't say it's impossible though.
Martin
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-01-29 21:15 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 20:32 [PATCH 00/35] RFC: add "nvme monitor" subcommand mwilck
2021-01-26 20:32 ` [PATCH 01/35] nvme-monitor: add new stub mwilck
2021-01-26 20:32 ` [PATCH 02/35] monitor: create udev socket mwilck
2021-01-26 20:32 ` [PATCH 03/35] monitor: initialize signal handling mwilck
2021-01-26 20:32 ` [PATCH 04/35] monitor: add main loop for uevent monitoring mwilck
2021-01-26 20:32 ` [PATCH 05/35] monitor: add uevent filters mwilck
2021-02-04 6:58 ` Hannes Reinecke
2021-01-26 20:32 ` [PATCH 06/35] monitor: Create a log() macro mwilck
2021-02-04 7:01 ` Hannes Reinecke
2021-02-04 9:14 ` Martin Wilck
2021-01-26 20:32 ` [PATCH 07/35] fabrics: use " mwilck
2021-02-04 7:02 ` Hannes Reinecke
2021-01-26 20:32 ` [PATCH 08/35] monitor: add command line options to control logging mwilck
2021-02-04 7:04 ` Hannes Reinecke
2021-02-04 9:18 ` Martin Wilck
2021-01-26 20:32 ` [PATCH 09/35] nvme_get_ctrl_attr(): constify "path" argument mwilck
2021-02-04 7:05 ` Hannes Reinecke
2021-01-26 20:32 ` [PATCH 10/35] fabrics: export do_discover(), build_options() and config mwilck
2021-02-04 7:09 ` Hannes Reinecke
2021-02-04 9:21 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 11/35] monitor: add option -A / --autoconnect mwilck
2021-01-29 18:59 ` Sagi Grimberg
2021-01-29 19:33 ` Martin Wilck
2021-01-29 20:09 ` Sagi Grimberg
2021-02-04 7:13 ` Hannes Reinecke
2021-01-26 20:33 ` [PATCH 12/35] monitor: add helpers for __attribute__((cleanup)) mwilck
2021-02-04 7:14 ` Hannes Reinecke
2021-01-26 20:33 ` [PATCH 13/35] monitor: disable nvmf-autoconnect udev rules in autoconnect mode mwilck
2021-01-29 1:52 ` Sagi Grimberg
2021-01-29 14:16 ` Martin Wilck
2021-01-29 18:54 ` Sagi Grimberg
2021-02-04 7:16 ` Hannes Reinecke
2021-02-04 9:37 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 14/35] monitor: implement handling of fc_udev_device mwilck
2021-01-26 20:33 ` [PATCH 15/35] monitor: implement handling of nvme AEN events mwilck
2021-01-26 20:33 ` [PATCH 16/35] monitor: reset children's signal disposition mwilck
2021-01-29 1:54 ` Sagi Grimberg
2021-01-29 14:18 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 17/35] monitor: handle SIGCHLD for terminated child processes mwilck
2021-01-29 1:54 ` Sagi Grimberg
2021-01-26 20:33 ` [PATCH 18/35] monitor: add "--persistent/-p" flag mwilck
2021-01-29 19:02 ` Sagi Grimberg
2021-01-29 19:45 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 19/35] fabrics: use "const char *" in struct config mwilck
2021-02-04 7:20 ` Hannes Reinecke
2021-01-26 20:33 ` [PATCH 20/35] fabrics: export arg_str(), parse_conn_arg(), and remove_ctrl() mwilck
2021-01-26 20:33 ` [PATCH 21/35] nvme-cli: add "list.h" mwilck
2021-01-26 20:33 ` [PATCH 22/35] conn-db: add simple connection registry mwilck
2021-01-29 1:59 ` Sagi Grimberg
2021-01-29 14:18 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 23/35] monitor: handle restart of pending discoveries mwilck
2021-01-26 20:33 ` [PATCH 24/35] monitor: monitor_discovery(): try to reuse existing controllers mwilck
2021-01-26 20:33 ` [PATCH 25/35] monitor: read existing connections on startup mwilck
2021-01-26 20:33 ` [PATCH 26/35] monitor: implement starting discovery controllers " mwilck
2021-01-29 21:06 ` Sagi Grimberg
2021-01-29 21:13 ` Martin Wilck
2021-01-29 21:18 ` Sagi Grimberg
2021-01-26 20:33 ` [PATCH 27/35] monitor: implement cleanup of created discovery controllers mwilck
2021-01-26 20:33 ` [PATCH 28/35] monitor: basic handling of add/remove uevents for nvme controllers mwilck
2021-01-26 20:33 ` [PATCH 29/35] monitor: kill running discovery tasks on exit mwilck
2021-01-26 20:33 ` [PATCH 30/35] monitor: add connection property options from connect-all mwilck
2021-01-26 20:33 ` [PATCH 31/35] completions: add completions for nvme monitor mwilck
2021-01-26 20:33 ` [PATCH 32/35] nvmf-autoconnect: add unit file for nvme-monitor.service mwilck
2021-01-29 19:08 ` Sagi Grimberg
2021-01-29 19:50 ` Martin Wilck
2021-01-26 20:33 ` [PATCH 33/35] nvme-connect-all(1): fix documentation for --quiet/-S mwilck
2021-01-29 19:09 ` Sagi Grimberg
2021-01-26 20:33 ` [PATCH 34/35] nvme-monitor(1): add man page for nvme-monitor mwilck
2021-01-26 20:33 ` [PATCH 35/35] monitor: add option --keep/-K mwilck
2021-01-29 19:10 ` Sagi Grimberg
2021-01-29 19:53 ` Martin Wilck
2021-01-29 20:16 ` Sagi Grimberg
2021-01-29 20:30 ` Martin Wilck
2021-01-29 20:45 ` Sagi Grimberg
2021-01-29 20:51 ` Martin Wilck
2021-01-29 20:57 ` Sagi Grimberg
2021-01-29 21:05 ` Martin Wilck
2021-01-29 21:11 ` Sagi Grimberg
2021-01-29 21:15 ` Martin Wilck [this message]
2021-01-29 21:21 ` Sagi Grimberg
2021-02-04 7:34 ` Hannes Reinecke
2021-02-04 9:41 ` Martin Wilck
2021-01-29 1:14 ` [PATCH 00/35] RFC: add "nvme monitor" subcommand Sagi Grimberg
2021-01-29 11:18 ` Martin Wilck
2021-01-29 20:08 ` Sagi Grimberg
2021-01-29 20:27 ` Martin Wilck
2021-02-04 7:52 ` Hannes Reinecke
2021-02-22 19:02 ` Enzo Matsumiya
2021-02-22 21:05 ` Martin Wilck
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=c00de29ef02bf39ae231a2816f03c8e920ebdc29.camel@suse.com \
--to=mwilck@suse.com \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=hare@suse.de \
--cc=kbusch@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox