From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============7548181961397510429=="
MIME-Version: 1.0
From: Michael Haeuptle <michaelhaeuptle at gmail.com>
Subject: Re: [SPDK] Multiple start/stop of reactor and add/remove of bdev
Date: Mon, 08 Oct 2018 13:24:34 -0600
Message-ID: <CAHUk8cTuT-EMnY6UxuQ6saS_i=smJ17AHUn1ZjSWFbWZbAQnnA@mail.gmail.com>
In-Reply-To: 7471B075-8986-4975-99B8-CB6CC097CAEE@intel.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

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

I can't comment on Shahar's use case but it would be helpful in cases where
I want to flex out reactors based on the # of devices which are not fixed.

In my use case, I don't really want to have reactors running if I don't
need them since they do incur some cost as far as I understand it (maybe
max_delay_us could be used).

For example, it may be good enough to have 1 reactor serving 2
vhost_scsi_controllers starting out. However, if I need to add more
controllers (since I want to add more devices), then I'd like to start
another reactor for the new vhost_scsi_controllers. Reducing controllers is
tricky but I'm not sure this happens very often in my use case.

-- Michael



On Mon, Oct 8, 2018 at 11:00 AM Harris, James R <james.r.harris(a)intel.com>
wrote:

> Hi Shahar,
>
> Can you describe why you require starting/stopping the reactor on demand?
>
> Thanks,
>
> -Jim
>
>
>
>
> On 10/8/18, 1:07 AM, "SPDK on behalf of Shahar Salzman" <
> spdk-bounces(a)lists.01.org on behalf of shahar.salzman(a)kaminario.com>
> wrote:
>
>     Hi,
>
>
>     I am now working with my passthrough bdev directly from my
> application, and require adding/removing them dynamically. In addition, I
> also require starting/stopping the reactor on demand without tearing down
> the entire system (e.g. dpdk stays initialized). This mostly works out of
> the box, but there are a few globals and bdev internal fields which requi=
re
> re-init or tear down.
>
>     In addition, the copy engine did not io_unregister itself, so I also
> added this in the patchset, allowing me the following application life sp=
an:
>
>
>     - env init (init config, spdk_env_init)
>
>     - reactors init
>
>     - while (application is alive)
>
>       subsystem_init + reactor start
>
>       ...
>
>       Do some NVMeF stuff
>
>       ...
>
>       subsysem_fini + reactors stop
>
>     - reactors_fini
>
>     - rpc_finish
>
>
>
>     I submitted the following patches for review:
>
>     https://review.gerrithub.io/c/spdk/spdk/+/428305
>
>     https://review.gerrithub.io/c/spdk/spdk/+/428304
>
>     https://review.gerrithub.io/c/spdk/spdk/+/428303
>
>     https://review.gerrithub.io/c/spdk/spdk/+/428302
>
>
>     WDYT?
>
>
>     Shahar
>     _______________________________________________
>     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
>

--===============7548181961397510429==--