[PATCH 3/3] nvmet: include all configured ports in the discovery log page

[Hannes Reinecke]

On 4/7/22 15:38, Sagi Grimberg wrote:
> 
>>>> When a per-port discovery subsystem is used we should include
>>>> all configured ports in the discovery log page, not just that one
>>>> through which the controller was connected.
>>>
>>> Why?
>>>
>> Because that's the whole point if it being configurable.
> 
> Maybe I'm missing something. It is one thing to allow configurable
> discovery NQNs, it is another thing to have discovery subsystems that
> are producing a log page about all connected ports.
>

Not all connected ports. All ports which have the _same_ discovery 
subsystem configured.

- /
   o- ports
   | o- 1 .. [trtype=tcp, traddr=127.0.0.1, trsvcid=8009]
   | | o- subsystems
   | |   o- nqn.discovery
   | o- 2 .. [trtype=tcp, traddr=127.0.0.1, trsvcid=4420]
   | | o- subsystems
   | |   o- nqn.discovery
   | |   o- nqn.io-1
   | o- 3 .. [trtype=tcp, traddr=127.0.0.1, trsvcid=4421]
   |   o- subsystems
   |     o- nqn.io-2
   o- subsystems
     o- nqn.discovery
     o- nqn.io-1
     | o- namespaces
     |   o- 1  [path=/tmp/ns1]
     |   o- 2  [path=/tmp/ns2]
     o- nqn.io-2
       o- namespaces
         o- 1  [path=/tmp/ns3]
         o- 2  [path=/tmp/ns4]

Here a discovery on port 8009 will print information about
- nqn.discovery at port 8009
- nqn.discovery at port 4420
- nqn.io-1 at port 4420
Discovery on port 4420 will get the same information, and discovery on 
port 4421 will return information about
- standard discovery subsyste on port 4421
- nqn.io-2 on port 4421

That's what I meant with 'configurable': you can define which 
information gets returned from which port.

> I suggest that if we want to have discovery subsystems that will
> produce entries on different ports, the log page content needs to be
> programmed explicitly in some form. Doing that is going to produce
> routing issues for sure (subnets, vlans, etc etc etc will cause hosts
> to get log entries for subsystems they can't connect to).

But this is nothing new, and in fact there are subsystem out there which 
_do_ provide log pages containing information about _all_ connected 
ports, even for different transport protocols.
And nvme-cli is already fixed up because of this.

But the whole point is that it _is_ configurable. If you don't want 
invalid entries, fine, configure it to not display potential invalid 
entries. The model allows you to create individual discovery subsystem 
for every port, simulating existing behaviour.
Or configure different discovery subsystem, and link them only to ports 
of the same type. Or same VLAN. Or whatever you care to.
Why should we restrict the choices here?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer