blktests: running nvme and srp tests with real RDMA hardware

blktests: running nvme and srp tests with real RDMA hardware

[Shinichiro Kawasaki]

Hello blktests users,

As of today, software RDMA driver "siw" or "rdma_rxe" is used to run "nvme"
group with nvme_trtype=rdma or "srp" (scsi rdma protocol) group. Now it is
suggested to run the test groups with real RDMA hardware to run tests in
more realistic conditions. A GitHub pull request is under review to support
it [1]. If you are interested in, please take a look and comment.

[1] https://github.com/osandov/blktests/pull/86

Re: blktests: running nvme and srp tests with real RDMA hardware

[Hannes Reinecke]

On 10/24/23 04:59, Shinichiro Kawasaki wrote:
> Hello blktests users,
> 
> As of today, software RDMA driver "siw" or "rdma_rxe" is used to run "nvme"
> group with nvme_trtype=rdma or "srp" (scsi rdma protocol) group. Now it is
> suggested to run the test groups with real RDMA hardware to run tests in
> more realistic conditions. A GitHub pull request is under review to support
> it [1]. If you are interested in, please take a look and comment.
> 
> [1] https://github.com/osandov/blktests/pull/86

Just commented on it. What we really need is the functionality to run 
against pre-configured controllers (ie specify the controller NQN and 
NSID and do not call into nvmetcli); when running on real HW we 
typically cannot control the target, so we need to be able to specify
a preconfigured namespace.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman

Re: blktests: running nvme and srp tests with real RDMA hardware

[Chaitanya Kulkarni]

On 10/23/23 22:43, Hannes Reinecke wrote:
> On 10/24/23 04:59, Shinichiro Kawasaki wrote:
>> Hello blktests users,
>>
>> As of today, software RDMA driver "siw" or "rdma_rxe" is used to run 
>> "nvme"
>> group with nvme_trtype=rdma or "srp" (scsi rdma protocol) group. Now 
>> it is
>> suggested to run the test groups with real RDMA hardware to run tests in
>> more realistic conditions. A GitHub pull request is under review to 
>> support
>> it [1]. If you are interested in, please take a look and comment.
>>
>> [1] https://github.com/osandov/blktests/pull/86
>
> Just commented on it. What we really need is the functionality to run 
> against pre-configured controllers (ie specify the controller NQN and 
> NSID and do not call into nvmetcli); when running on real HW we 
> typically cannot control the target, so we need to be able to specify
> a preconfigured namespace.
>
> Cheers,
>
> Hannes

What format you think use to accept the pre configured namespace ?
thinking out loudly Can relay and we use nvmetcli config file somehow
for local loop back setup ?

-ck

Re: blktests: running nvme and srp tests with real RDMA hardware

[Hannes Reinecke]

On 10/24/23 07:55, Chaitanya Kulkarni wrote:
> On 10/23/23 22:43, Hannes Reinecke wrote:
>> On 10/24/23 04:59, Shinichiro Kawasaki wrote:
>>> Hello blktests users,
>>>
>>> As of today, software RDMA driver "siw" or "rdma_rxe" is used to run
>>> "nvme"
>>> group with nvme_trtype=rdma or "srp" (scsi rdma protocol) group. Now
>>> it is
>>> suggested to run the test groups with real RDMA hardware to run tests in
>>> more realistic conditions. A GitHub pull request is under review to
>>> support
>>> it [1]. If you are interested in, please take a look and comment.
>>>
>>> [1] https://github.com/osandov/blktests/pull/86
>>
>> Just commented on it. What we really need is the functionality to run
>> against pre-configured controllers (ie specify the controller NQN and
>> NSID and do not call into nvmetcli); when running on real HW we
>> typically cannot control the target, so we need to be able to specify
>> a preconfigured namespace.
>>
>> Cheers,
>>
>> Hannes
> 
> What format you think use to accept the pre configured namespace ?
> thinking out loudly Can relay and we use nvmetcli config file somehow
> for local loop back setup ?
> 
Ideally I would hide it behind the call to '_setup_nvmet' / 
'_nvmet_target_setup' / '_nvmet_target_cleanup'.
We already have 'def_subsysnqn', which should be set to the
pre-provisioned NQN. We clearly need a 'def_nsid', but that
should be easily done.

Biggest problem here will be the 'out' files. Most of them record the
default NQN, so if we allow to change that the tests will break.
How can we abstract away from that?

Maybe it's a good exercise even with the current codebase; just
set 'def_subsysnqn' to something else and watch what breaks ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman

Re: blktests: running nvme and srp tests with real RDMA hardware

[Bart Van Assche]

On 10/23/23 19:59, Shinichiro Kawasaki wrote:
> Hello blktests users,
> 
> As of today, software RDMA driver "siw" or "rdma_rxe" is used to run "nvme"
> group with nvme_trtype=rdma or "srp" (scsi rdma protocol) group. Now it is
> suggested to run the test groups with real RDMA hardware to run tests in
> more realistic conditions. A GitHub pull request is under review to support
> it [1]. If you are interested in, please take a look and comment.
> 
> [1] https://github.com/osandov/blktests/pull/86

When I wrote the SRP tests, my goal was to test the SRP initiator
driver, SRP target driver and dm-multipath drivers and also to allow
users who do not have RDMA hardware to run these tests. Running these
tests against a real RDMA adapter tests other functionality than block
layer code. I see this as a use case that falls outside the original
scope of the blktests test suite. Running NVMe tests against a real
storage array also falls outside the scope of testing block driver
functionality. I'm fine with adding this functionality but I hope that
it does not become a burden for blktests contributors who are not
interested in maintaining functionality that falls outside the original
scope of blktests.

Bart.