Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230620133711.22840-1-dwagner@suse.de> <20230620133711.22840-5-dwagner@suse.de>
 <594f73f2-59b0-bbcb-d7a0-6d89e2446830@gmail.com> <7kcc75btp5bo5oqjnpqlwwo37l2f4atwfemknbmvqagrqicl2i@njn4tai7e4m7>
In-Reply-To: <7kcc75btp5bo5oqjnpqlwwo37l2f4atwfemknbmvqagrqicl2i@njn4tai7e4m7>
From:   Ewan Milne <emilne@redhat.com>
Date:   Thu, 13 Jul 2023 16:35:33 -0400
Message-ID: <CAGtn9rmDDqXKH2XfqKXww7aOKmNG6vwuPEsy6bXmABaWvHvd7Q@mail.gmail.com>
Subject: Re: [PATCH v2 4/5] nvme-fc: Make initial connect attempt synchronous
To:     Daniel Wagner <dwagner@suse.de>
Cc:     James Smart <jsmart2021@gmail.com>, linux-nvme@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
        Chaitanya Kulkarni <kch@nvidia.com>,
        "Shin'ichiro Kawasaki" <shinichiro@fastmail.com>,
        Sagi Grimberg <sagi@grimberg.me>,
        Hannes Reinecke <hare@suse.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

The basic issue I am trying to solve with NVMe/FC is that we cannot get sys=
tems
to boot reliably from NVMe/FC (boot from SAN) because we don't know how lon=
g
the connect is going to take, and we have seen spurious failures in our tes=
ting.

In general, I think the whole business of a userspace syscall() -> asynchro=
nous
work in the kernel is problematic because the syscall can return a good sta=
tus
even if the connect is never going to work due to a condition that is
not going to
clear.  It is difficult and cumbersome to script around this reliably.

So what I am saying is the current mechanism doesn't work completely
right anyway.

We also encounter the problem Daniel is addressing trying to get
blktests and other
internal tests to work, for similar reasons.

-Ewan

On Thu, Jul 6, 2023 at 8:07=E2=80=AFAM Daniel Wagner <dwagner@suse.de> wrot=
e:
>
> Hi James,
>
> On Sat, Jul 01, 2023 at 05:11:11AM -0700, James Smart wrote:
> > As much as you want to make this change to make transports "similar", I=
 am
> > dead set against it unless you are completing a long qualification of t=
he
> > change on real FC hardware and FC-NVME devices. There is probably 1.5 y=
rs of
> > testing of different race conditions that drove this change. You cannot
> > declare success from a simplistic toy tool such as fcloop for validatio=
n.
> >
> > The original issues exist, probably have even morphed given the time fr=
om
> > the original change, and this will seriously disrupt the transport and =
any
> > downstream releases.  So I have a very strong NACK on this change.
> >
> > Yes - things such as the connect failure results are difficult to retur=
n
> > back to nvme-cli. I have had many gripes about the nvme-cli's behavior =
over
> > the years, especially on negative cases due to race conditions which
> > required retries. It still fails this miserably.  The async reconnect p=
ath
> > solved many of these issues for fc.
> >
> > For the auth failure, how do we deal with things if auth fails over tim=
e as
> > reconnects fail due to a credential changes ?  I would think commonalit=
y of
> > this behavior drives part of the choice.
>
> Alright, what do you think about the idea to introduce a new '--sync' opt=
ion to
> nvme-cli which forwards this info to the kernel that we want to wait for =
the
> initial connect to succeed or fail? Obviously, this needs to handle signa=
ls too.
>
> From what I understood this is also what Ewan would like to have.
>
> Hannes thought it would make sense to use the same initial connect logic =
in
> tcp/rdma, because there could also be transient erros (e.g. spanning tree
> protocol). In short making the tcp/rdma do the same thing as fc?
>
> So let's drop the final patch from this series for the time. Could you gi=
ve some
> feedback on the rest of the patches?
>
> Thanks,
> Daniel
>