Re: [PATCH 1/6] nvmeof-tcp/001: simple test for nvmeof-tcp connection
From: Chaitanya Kulkarni <hidden>
Date: 2021-11-15 02:34:30
Hannes, On 11/14/2021 6:45 AM, Sagi Grimberg wrote:
On 11/14/21 3:50 PM, Hannes Reinecke wrote:quoted
On 11/14/21 11:31 AM, Sagi Grimberg wrote:quoted
quoted
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.quoted
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.quoted
We could rename it to nvmeof-auth, though.or just add it as more tests under nvme (or create a subdirectory).quoted
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...