[PATCH v4] nvmet: force reconnect when number of queue changes

[Daniel Wagner]

On Wed, Oct 26, 2022 at 07:53:56AM +0200, Hannes Reinecke wrote:
> > Without looking into the spec, isn't some sort of AEN should be used for
> > this ? please correct me if I'm wrong but deleting all the controllers
> > and relaying on reconnect maybe overkill ? if it doesn't exists in
> > the NVMe spec then perhaps we should think/work on it to update the
> > spec ? Is it worth it ?

As it turns out there is no AEN which really matches this. We scenario
had a short discussion on this topic with Fred during ALPSS and he was
not against adding something if there is a good use case for it.

The issue is that no one really came up with a good general use case
except for testing corner cases.

> Problem is that changing the number of queues on the fly is really awkward,
> _and_ you have the problem that the number of queues is negotiated during
> the 'connect' call. So changing the number of queues from the controller
> side really requires us to reconnect to rectify the situation.
> 
> And no, I don't think it's overkill. It actually makes the situation easier
> as you start off from scratch with the correct number of queues.

There is also the argument, that this approach doesn't rely on the host
to cooperate correctly. For example, if we had an AEN to tell the host
'hey, drop all connections and reconnect', the target still doesn't know
when and if this has been done by the host.