[RFC 0/2] nvme/loop: Add support for controllers-per-port model

[Christoph Hellwig]

On Wed, Jun 08, 2016 at 10:13:53PM -0700, Nicholas A. Bellinger wrote:
> I still don't see why a loopback controller on a port of an individual
> subsystem NQN can't be created + deleted directly from configfs, and
> operate independently of other loopback controllers on a port of a
> different subsystem NQNs.

I think you are misunderstanding the NVMe entities - there is no port
of a subsystem.  There are port, and there are subsystems and there
is an N to M relation between them, not an N to one relation.

Multiple controllers may and usually will use the same port to access
one or more subsystems, but multiple controllers may also use different
ports to use the same subsystem.

For full NVMe functionality we thus need to be able to create all
these objects indepdently.   While loopback ports are extremtly cheap
I see no reason to introduce a shortcut to break this model for our
debug local implementation - the whole point of the loopback driver
is to give you the full NVMe over Fabrics experience without needing
an (possibly expensive) transport.

> > Something like the patch below is the right way, it just needs a bit more
> > fine tuning and proper test cases:
> 
> I don't see how adding a internal mutex for loopback ports, and doing
> internal sequential list lookup holding the global nvmet_config_sem
> whilst doing nvmet_fabric_ops->add_port() helps to scale at all..

Scalability of the controller creation is not the prime goal for the
nvme-loop driver.  It's supposed to be the simples possible implementation
of a NVMe over Fabrics transport.

> AFAICT for loopback, neither of these is necessary.  Why can't a
> loopback controller on a port for a individual subsystem NQN be created
> + deleted directly from configfs,

We could trivially do this, but I think it's counter productive.  NVMe
over Fabrics does not automatically create one or multiple controllers,
and nvme-loop is just another transport that follows the higher level
spec.

> independent of other subsystem NQN's
> loopback controller ports..?

The only limitation at the moment is that there is only one port.  I've
shown you a fairly trivial patch to lift that limitation.  Subsystem
can be created and deleted independently from each other, as can
controllers, and as can ports for transport where more than one can
exists.