Re: [PATCH 1/6] nvmeof-tcp/001: simple test for nvmeof-tcp connection

[Chaitanya Kulkarni <chaitanyak@nvidia.com>]

Hannes,

On 11/14/2021 6:45 AM, Sagi Grimberg wrote:
> 
> 
> On 11/14/21 3:50 PM, Hannes Reinecke wrote:
>> On 11/14/21 11:31 AM, Sagi Grimberg wrote:
>>>
>>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>>>> ---
>>>>   tests/nvmeof-tcp/001     |  55 +++++++
>>>>   tests/nvmeof-tcp/001.out |   6 +
>>>>   tests/nvmeof-tcp/rc      | 347 
>>>> +++++++++++++++++++++++++++++++++++++++
>>>
>>> Why another directory? why nvmeof-tcp? what prevents inband-auth
>>> to be tested with loop/rdma?
>>>
>> Technically, nothing.
>> But as I'll be looking into tcp in-band _encryption_ as the next step 
>> I found it logical to have a disinct directory.
> 
> It is unclear to me why the separate directory is needed. But at least
> call it something else if you must have it.
> 
>> Especially as I still fail to see the actual use-case for using 
>> in-band authentication _without_ encryption.
> 
> Not sure what you mean. For the same use-case that iscsi chap exists
> for. The secrets are pre-shared.
> 
> Perhaps you can explain? My understanding is that the extension for
> nvme-tcp TLS based auth is to avoid maintaining two sets of pre-shared
> keys, i.e just maintain the TLS ones and not the dhchap ones. But maybe
> I am missing something.
> 
>> We could rename it to nvmeof-auth, though.
> 
> or just add it as more tests under nvme (or create a subdirectory).
> 
>> Especially as there's the nvmeof-mp precedent, which also has a 
>> separate directory.
> 
> That one is for nvme and dm-multipath, not really a native suite for
> nvme.
> 


It will be great if we can avoid crating a different directory as we
need to make make sure our tests are generic and can be applied to
different transports and new testcases that will get added to nvme
category (non-mp) can use this and existing infrastructure...