From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: Hannes Reinecke <hare@suse.de>, Daniel Wagner <dwagner@suse.de>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, Chaitanya Kulkarni <kch@nvidia.com>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
Sagi Grimberg <sagi@grimberg.me>,
James Smart <jsmart2021@gmail.com>,
Martin Belanger <Martin.Belanger@dell.com>
Subject: Re: [PATCH blktests v1 2/3] nvme/rc: Avoid triggering host nvme-cli autoconnect
Date: Thu, 13 Jul 2023 11:49:32 +0300 [thread overview]
Message-ID: <bd7c91c4-9528-aaeb-9789-03191dc7761b@nvidia.com> (raw)
In-Reply-To: <95210a8a-c70e-c312-2c47-4f5ee9329586@suse.de>
On 13/07/2023 9:00, Hannes Reinecke wrote:
> On 7/13/23 02:12, Max Gurtovoy wrote:
>>
>>
>> On 12/07/2023 15:04, Daniel Wagner wrote:
>>> On Mon, Jul 10, 2023 at 07:30:20PM +0300, Max Gurtovoy wrote:
>>>>
>>>>
>>>> On 10/07/2023 18:03, Daniel Wagner wrote:
>>>>> On Mon, Jul 10, 2023 at 03:31:23PM +0300, Max Gurtovoy wrote:
>>>>>> I think it is more than just commit message.
>>>>>
>>>>> Okay, starting to understand what's the problem.
>>>>>
>>>>>> A lot of code that we can avoid was added regarding the --context
>>>>>> cmdline
>>>>>> argument.
>>>>>
>>>>> Correct and it's not optional to get the tests passing for the fc
>>>>> transport.
>>>>
>>>> why the fc needs the --context to pass tests ?
>>>
>>> A typical nvme test consists out of following steps (nvme/004):
>>>
>>> // nvme target setup (1)
>>> _create_nvmet_subsystem "blktests-subsystem-1" "${loop_dev}" \
>>> "91fdba0d-f87b-4c25-b80f-db7be1418b9e"
>>> _add_nvmet_subsys_to_port "${port}" "blktests-subsystem-1"
>>>
>>> // nvme host setup (2)
>>> _nvme_connect_subsys "${nvme_trtype}" blktests-subsystem-1
>>>
>>> local nvmedev
>>> nvmedev=$(_find_nvme_dev "blktests-subsystem-1")
>>> cat "/sys/block/${nvmedev}n1/uuid"
>>> cat "/sys/block/${nvmedev}n1/wwid"
>>>
>>> // nvme host teardown (3)
>>> _nvme_disconnect_subsys blktests-subsystem-1
>>>
>>> // nvme target teardown (4)
>>> _remove_nvmet_subsystem_from_port "${port}" "blktests-subsystem-1"
>>> _remove_nvmet_subsystem "blktests-subsystem-1"
>>>
>>>
>>> The corresponding output with --context
>>>
>>> run blktests nvme/004 at 2023-07-12 13:49:50
>>> // (1)
>>> loop0: detected capacity change from 0 to 32768
>>> nvmet: adding nsid 1 to subsystem blktests-subsystem-1
>>> nvme nvme2: NVME-FC{0}: create association : host wwpn
>>> 0x20001100aa000002 rport wwpn 0x20001100aa000001: NQN
>>> "blktests-subsystem-1"
>>> (NULL device *): {0:0} Association created
>>> [174] nvmet: ctrl 1 start keep-alive timer for 5 secs
>>> // (2)
>>> nvmet: creating nvm controller 1 for subsystem blktests-subsystem-1
>>> for NQN
>>> nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
>>> [374] nvmet: adding queue 1 to ctrl 1.
>>> [1138] nvmet: adding queue 2 to ctrl 1.
>>> [73] nvmet: adding queue 3 to ctrl 1.
>>> [174] nvmet: adding queue 4 to ctrl 1.
>>> nvme nvme2: NVME-FC{0}: controller connect complete
>>> nvme nvme2: NVME-FC{0}: new ctrl: NQN "blktests-subsystem-1"
>>> // (3)
>>> nvme nvme2: Removing ctrl: NQN "blktests-subsystem-1"
>>> // (4)
>>> [1138] nvmet: ctrl 1 stop keep-alive
>>> (NULL device *): {0:0} Association deleted
>>> (NULL device *): {0:0} Association freed
>>> (NULL device *): Disconnect LS failed: No Association
>>>
>>>
>>> and without --context
>>>
>>> run blktests nvme/004 at 2023-07-12 13:50:33
>>> // (1)
>>> loop1: detected capacity change from 0 to 32768
>>> nvmet: adding nsid 1 to subsystem blktests-subsystem-1
>>> nvme nvme2: NVME-FC{0}: create association : host wwpn
>>> 0x20001100aa000002 rport wwpn 0x20001100aa000001: NQN
>>> "nqn.2014-08.org.nvmexpress.discovery"
>>
>> why does this association to discovery controller created ? because of
>> some system service ?
>>
> Yes. There are nvme-autoconnect udev rules and systemd services
> installed per default (in quite some systems now).
> And it's really hard (if not impossible) to disable these services (as
> we cannot be sure how they are named, hence we wouldn't know which
> service to disable.
Right. We shouldn't disable them IMO.
>
>> can we configure the blktests subsystem not to be discovered or add
>> some access list to it ?
>>
> But that's precisely what the '--context' thing is attempting to do ...
I'm not sure it is.
Exposing the subsystem is from the target configuration side.
Additionally, the --context (which is in the initiator/host side),
according to Daniel, is there to distinguish between different
invocations. I proposed that blktests subsystem will not be part of
discoverable fabric or protected somehow by access list. Therefore, no
additional invocation will happen.
>
> [ .. ]
>>>>>
>>>>> It really solves the problem that the autoconnect setup of nvme-cli is
>>>>> distrubing the tests (*). The only other way I found to stop the
>>>>> autoconnect is by disabling the udev rule completely. If
>>>>> autoconnect isn't enabled the context isn't necessary.
>>>>> Though changing system configuration from blktests seems at bit
>>>>> excessive.
>>>>
>>>> we should not stop any autoconnect during blktests. The autoconnect
>>>> and all the system admin services should run normally.
>>>
>>> I do not agree here. The current blktests are not designed for run as
>>> intergration tests. Sure we should also tests this but currently
>>> blktests is just not there and tcp/rdma are not actually covered anyway.
>>
>> what do you mean tcp/rdma not covered ?
>>
> Because there is no autoconnect functionality for tcp/rdma.
> For FC we have full topology information, and the driver can emit udev
> messages whenever a NVMe port appears in the fabrics (and the systemd
> machinery will then start autoconnect).
> For TCP/RDMA we do not have this, so really there's nothing which could
> send udev events (discounting things like mDNS and nvme-stas for now).
>
>> And maybe we should make several changes in the blktests to make it
>> standalone without interfering the existing configuration make by some
>> system administrator.
>>
> ??
> But this is what we are trying with this patches.
> The '--context' flag only needs to be set for the blktests, to inform
> the rest of the system that these subsystems/configuration is special
> and should be exempted from 'normal' system processing.
The --context is initiator configuration. I'm referring to changes in
the target configuration.
This will guarantee that things will work also in the environment where
we have nvme-cli without the --context flag.
>
> Cheers,
>
> Hannes
next prev parent reply other threads:[~2023-07-13 8:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 13:27 [PATCH blktests v1 0/3] More fixes for FC enabling Daniel Wagner
2023-06-20 13:27 ` [PATCH blktests v1 1/3] nvme/048: Check for queue count check directly Daniel Wagner
2023-06-20 13:49 ` Sagi Grimberg
2023-06-20 17:37 ` Daniel Wagner
2023-06-21 9:50 ` Sagi Grimberg
2023-06-21 11:19 ` Daniel Wagner
2023-06-27 10:13 ` Shinichiro Kawasaki
2023-06-28 5:52 ` Daniel Wagner
2023-06-20 13:27 ` [PATCH blktests v1 2/3] nvme/rc: Avoid triggering host nvme-cli autoconnect Daniel Wagner
2023-06-20 14:07 ` Sagi Grimberg
2023-06-20 17:43 ` Daniel Wagner
2023-06-21 9:02 ` Daniel Wagner
2023-06-27 10:22 ` Shinichiro Kawasaki
2023-06-28 6:09 ` Daniel Wagner
2023-06-28 10:04 ` Shinichiro Kawasaki
2023-06-28 15:00 ` Daniel Wagner
2023-07-06 16:11 ` Max Gurtovoy
2023-07-10 8:27 ` Daniel Wagner
2023-07-10 9:53 ` Max Gurtovoy
2023-07-10 10:19 ` Daniel Wagner
2023-07-10 12:31 ` Max Gurtovoy
2023-07-10 15:03 ` Daniel Wagner
2023-07-10 16:30 ` Max Gurtovoy
2023-07-12 12:04 ` Daniel Wagner
2023-07-13 0:12 ` Max Gurtovoy
2023-07-13 6:00 ` Hannes Reinecke
2023-07-13 8:49 ` Max Gurtovoy [this message]
2023-07-13 10:14 ` Hannes Reinecke
2023-07-13 10:30 ` Daniel Wagner
2023-07-13 10:44 ` Daniel Wagner
2023-07-13 10:50 ` Max Gurtovoy
2023-06-20 13:27 ` [PATCH blktests v1 3/3] nvme/{041,042,043,044,045}: Use default hostnqn and hostid Daniel Wagner
2023-06-27 10:24 ` Shinichiro Kawasaki
2023-07-06 16:06 ` Max Gurtovoy
2023-07-10 8:32 ` Daniel Wagner
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=bd7c91c4-9528-aaeb-9789-03191dc7761b@nvidia.com \
--to=mgurtovoy@nvidia.com \
--cc=Martin.Belanger@dell.com \
--cc=dwagner@suse.de \
--cc=hare@suse.de \
--cc=jsmart2021@gmail.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=shinichiro.kawasaki@wdc.com \
/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