From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============0209905486046225061=="
MIME-Version: 1.0
From: Stojaczyk, Dariusz <dariusz.stojaczyk at intel.com>
Subject: Re: [SPDK] spdk_bdev_close() threading
Date: Fri, 05 Apr 2019 19:32:11 +0000
Message-ID: <FBE7E039FA50BF47A673AD0BD3CD56A84630274F@HASMSX105.ger.corp.intel.com>
In-Reply-To: 130299e01ddaee0d11a847cc4bf7d54997cd6dae.camel@intel.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============0209905486046225061==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker,
> Benjamin
> Sent: Friday, April 5, 2019 7:11 PM
> To: spdk(a)lists.01.org
> Subject: Re: [SPDK] spdk_bdev_close() threading
> =

> <snip>
>
> Note that the NVMe-oF target has a designated thread for each NVMe-oF
> subsystem,
> and all operations on that subsystem (including all bdev opens and closes)
> get
> funneled there. It then has additional infrastructure to send a message to
> every
> thread in the target to either update local data caches or to pause/resume
> I/O
> on those threads.
> =

> NVMe-oF has some issues to work out with hotplug at the moment, but
> design-wise
> I think the threading model it uses is the right one and we need to move
> both
> vhost and iSCSI to a similar model. The way the NVMe-oF target works is a=
lso
> ideal for the upcoming lightweight threading changes.

Maybe. I guess I still need some more arguments as to why we would
want to enforce the application (possibly a user application) to behave this
way. Why wouldn't we give it a free hand?

D.

> =

> >
> > > I know there are some cases where we have to do locking in SPDK.  But
> I'd
> > > rather avoid adding it if possible.  This stuff is inherently difficu=
lt to
> > > really to
> > > test and ensure we get right.  This patch may only be about 120 lines=
 of
> > > code,
> > > but we don't have any tests to make sure it's correct.
> >
> > I'm not sure if you saw them - this patch contains some unit tests for
> > spdk_bdev_close() called concurrently with spdk_bdev_unregister() on
> > a different thread. I stress-tested the real case scenario in vhost loc=
ally,
> > but
> > as for the CI, those unit tests are the best I can push right now.
> >
> > D.
> >
> > > -Jim
> > >
> > >
> > >     It doesn't affect any use cases which close the descriptor on the=
 same
> > >     thread that opened it - it only lifts those single thread limitat=
ions.
> > >
> > >     D.
> > >
> > >     >
> > >     > -Jim
> > >     >
> > >     >
> > >     > _______________________________________________
> > >     > SPDK mailing list
> > >     > SPDK(a)lists.01.org
> > >     > https://lists.01.org/mailman/listinfo/spdk
> > >     _______________________________________________
> > >     SPDK mailing list
> > >     SPDK(a)lists.01.org
> > >     https://lists.01.org/mailman/listinfo/spdk
> > >
> > >
> > > _______________________________________________
> > > SPDK mailing list
> > > SPDK(a)lists.01.org
> > > https://lists.01.org/mailman/listinfo/spdk
> > _______________________________________________
> > SPDK mailing list
> > SPDK(a)lists.01.org
> > https://lists.01.org/mailman/listinfo/spdk
> =

> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

--===============0209905486046225061==--