[SPDK] Re: NVMe Multipath subsystem controller IDs

Hi Jonathan, Ben,

I'm not an expert in this area but supporting multiple SPDK target
instances is also important to iSCSI.
I see the value of per-subsystem controller ID range and it is already
added to Linux target.

But we have little auto test for multiple SPDK target instances.
Could you enhance test/nvmf/target/multitarget.sh to verify the feature?

And do we have negative side effect if we support per-subsystem controller
ID range?

Thanks,
Shuhei

On Wed, Apr 7, 2021 at 1:09 AM Jonathan Teh <jonathan.teh(a)mayadata.io>
wrote:

> On 01/04/2021 22:57, Walker, Benjamin wrote:
> > Exposing the same subsystem from two nodes is still certainly
> problematic. I think all of the
> > issues I listed in that thread are still valid (reservations, discovery,
> etc.) A better solution is likely
> > namespaces shared across subsystems, but that is not in the NVMe
> specification today.
>
> Understood, we have solutions being considered for other issues
> (essentially something to orchestrate the multiple SPDK instances).
>
> > Could we make an API in include/spdk/nvmf.h to allow the user to
> register a function pointer for generating
> > the controller ids? Maybe just stick a function pointer into
> spdk_nvmf_target_opts. Then you can use whatever
> > algorithm you want. How does that sound?
>
> That's certainly another option and gives maximum flexibility though it
> means a standalone, unmodified SPDK can only used the built-in
> controller ID generation function, perhaps ruling out some quick
> experiments.
>
> I have already implemented the per-subsystem controller ID range in SPDK
> and it is a fairly small patch. It gives some flexibility without having
> the complexity of having to supply your own implementation of controller
> ID generation and maintaining the state of that per-subsystem.
> _______________________________________________
> SPDK mailing list -- spdk(a)lists.01.org
> To unsubscribe send an email to spdk-leave(a)lists.01.org
>