From: Laurence Oberman <loberman@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>,
linux-rdma <linux-rdma@vger.kernel.org>,
"Dutile, Don" <ddutile@redhat.com>
Cc: Rupesh Girase <rgirase@redhat.com>
Subject: Re: 5.3-rc8 tests all pass with RDMA/SRP testing
Date: Wed, 18 Sep 2019 12:17:32 -0400 [thread overview]
Message-ID: <ae55e946c8d355f5c1e2e4f4575c76b44cd8d14f.camel@redhat.com> (raw)
In-Reply-To: <c9e449ab-23d6-0036-7056-8c49e4efdf0b@acm.org>
On Tue, 2019-09-17 at 10:59 -0700, Bart Van Assche wrote:
> On 9/12/19 12:48 PM, Laurence Oberman wrote:
> > My usual 3 month SRP test results show all is still well with SRP
> > client drivers and multipath.
> > I am still using 4.16 for the ib_srpt on the target server.
> >
> > 5.3-rc8 ib_srp CX4 100Gbit EDR tests
> > direct and unbuffered, large and small I/O sizes
> > port recovery with fault injection
> >
> > One small observation was that after fault injection it seemed to
> > take
> > longer to log back in, in that I needed to extend my sleep in the
> > injection script to avoid some multipaths lose all paths.
> >
> > I was sleeping 30s between resets prior to this and I would log
> > back in
> > quick enough to not lose all paths.
> > My sleep is now 60s
> >
> > #on ibclient server in /sys/class/srp_remote_ports, using echo 1 >
> > delete for the particular port will simulate a port reset.
> >
> > #/sys/class/srp_remote_ports
> > #[root@ibclient srp_remote_ports]# ls
> > #port-1:1 port-2:1
> > for d in /sys/class/srp_remote_ports/*
> > do
> > echo 1 > $d/delete
> > sleep 60
> > done
>
> Hi Laurence,
>
> This is weird. Has this behavior change been observed once or has it
> been observed multiple times? I'm asking because in my tests I
> noticed
> that there can be variation between tests depending on how much time
> the
> SCSI error handler spends in its error recovery strategy.
>
> Thanks,
>
> Bart.
Hi Bart,
Well the tests have been at 30s for quite a while.
The 30s used to be long enough to get by in my tests.
I would have to go back a bit to see when it started seeing these
longer delays but I fully expect it to be related to EH changes to be
honest.
When I started getting hard errors I realized I was taking the second
port out before the first had recovered now.
Just let you know in case you have to change your blktests etc.
Thanks
Laurence
prev parent reply other threads:[~2019-09-18 16:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 19:48 5.3-rc8 tests all pass with RDMA/SRP testing Laurence Oberman
2019-09-17 17:59 ` Bart Van Assche
2019-09-18 16:17 ` Laurence Oberman [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=ae55e946c8d355f5c1e2e4f4575c76b44cd8d14f.camel@redhat.com \
--to=loberman@redhat.com \
--cc=bvanassche@acm.org \
--cc=ddutile@redhat.com \
--cc=linux-rdma@vger.kernel.org \
--cc=rgirase@redhat.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;
as well as URLs for NNTP newsgroup(s).