Re: [PATCH 3/4] nvme-fabrics: add tp8010 support

[John Meneghini <jmeneghi@redhat.com>]

OK. Thanks Martin.  That explains it.

On 1/31/22 12:17, Belanger, Martin wrote:
>> Hi Martin.
>>
>> Properly speaking, registrations are sent to the CDC, not the DC.
>>
>> Correct?
>>
>> Can we please change this, everywhere, to be clear about when we are
>> "talking" to the CDC (Centralized Discovery Controller) and when we are
>> talking to the DC (Discovery Controller).
>>
>> /John
> 
> Hi John.
> 
> TP8010 originally intended for registration (DIM PDU) to be sent
> to CDCs only. However, this was changed to include Direct Discovery
> Controllers (DDC)  as well. That's why I use DC and not CDC.
> 
> Also note that TP8010 introduces a new DCTYPE field in the response to
> the Identify command, which is used to differentiate between a CDC and
> a DDC. Legacy DCs that do not comply to TP8010 will have DCTYPE=0
> (i.e. Discovery controller type is not reported). So, registration will not
> be attempted  for DCTYPE other than 1 (DDC) and 2 (CDC).
> 
> Here you will find the ratified version of TP8010:
> https://nvmexpress.org/wp-content/uploads/NVM-Express-2.0-Ratified-TPs-01242022.zip
> 
> Martin
> 
>>
>> On 1/25/22 09:59, Martin Belanger wrote:
>>> +/**
>>> + * nvme_get_adrfam() - Get address family for the address we're
>>> +registering
>>> + * with the DC. We retrieve this info from the socket itself. If we
>>> +can't
>>> + * get the source address from the socket, then we'll infer the
>>> +address
>>> + * family from the address of the DC since the DC address has the
>>> +same
>>> + * address family.
>>> + *
>>> + * @ctrl: Host NVMe controller instance maintaining the admin queue
>> used to
>>> + *      submit the DIM command to the DC.
>>> + *
>>> + * Return: The address family of the source address associated with
>>> +the
>>> + * socket connected to the DC.
> 
> 
> Internal Use - Confidential