| Message ID | 20250318-test-target-v1-2-01e01142cf2b@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | blktests: add target test cases | expand |
On 3/18/25 03:39, Daniel Wagner wrote: > Newer kernel support to reset the target via the debugfs. Add a new test > case which exercises this interface. > > Signed-off-by: Daniel Wagner<wagi@kernel.org> Looks useful to me given that its a different code path in the target. do we have any testcaes similar for non-debugfs code path ? (don't remember at this point) Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> -ck
On Tue, Mar 18, 2025 at 08:40:39PM +0000, Chaitanya Kulkarni wrote: > On 3/18/25 03:39, Daniel Wagner wrote: > > Newer kernel support to reset the target via the debugfs. Add a new test > > case which exercises this interface. > > > > Signed-off-by: Daniel Wagner<wagi@kernel.org> > > Looks useful to me given that its a different code path in the target. One thing I forgot to add a check if the feature is available. I think the only way is to setup a target and see if the relevant file shows up... > do we have any testcaes similar for non-debugfs code path ? > (don't remember at this point) There is not direct way to trigger a target reset via a nvme command yet. The upcoming TP8028 brings cross controller reset. We have an indirect way to trigger a reset, via changing the number of queues the target supports (this test case is already there).
On 3/19/25 02:26, Daniel Wagner wrote: > On Tue, Mar 18, 2025 at 08:40:39PM +0000, Chaitanya Kulkarni wrote: >> On 3/18/25 03:39, Daniel Wagner wrote: >>> Newer kernel support to reset the target via the debugfs. Add a new test >>> case which exercises this interface. >>> >>> Signed-off-by: Daniel Wagner<wagi@kernel.org> >> Looks useful to me given that its a different code path in the target. > One thing I forgot to add a check if the feature is available. I think > the only way is to setup a target and see if the relevant file shows > up... perhaps create a controller and in absence of NVMET_DFS skipping the test with right reason is a way to go ? It will also be helpful if you just create a helper that will create a controller that way any future tests that needs to check for specific feature via configfs files can use it. That helper will also get called from requires() in order to set the right SKIP_REASON. >> do we have any testcaes similar for non-debugfs code path ? >> (don't remember at this point) > There is not direct way to trigger a target reset via a nvme command > yet. The upcoming TP8028 brings cross controller reset. It will be nice. > We have an indirect way to trigger a reset, via changing the number of > queues the target supports (this test case is already there). ahh thanks.. -ck
diff --git a/tests/nvme/060 b/tests/nvme/060 new file mode 100755 index 0000000000000000000000000000000000000000..16a3c0d20274428ae175693109c694f42004a619 --- /dev/null +++ b/tests/nvme/060 @@ -0,0 +1,88 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-3.0+ +# Copyright (C) 2025 Daniel Wagner, SUSE Labs +# +# Test nvme fabrics controller reset/disconnect/reconnect operation during I/O +# This test is somewhat similar to test 032 but for fabrics controllers. + +. tests/nvme/rc + +DESCRIPTION="test nvme fabrics target resetting during I/O" + +requires() { + _nvme_requires + _have_loop + _have_fio + _require_nvme_trtype_is_fabrics +} + +set_conditions() { + _set_nvme_trtype "$@" +} + +nvmet_debug_trigger_reset() { + local nvmet_subsystem="$1" + local dfs_path="${NVMET_DFS}/${nvmet_subsystem}" + + find "${dfs_path}" -maxdepth 1 -type d -name 'ctrl*' -exec sh -c 'echo "fatal" > "$1/state"' _ {} \; +} + +nvmf_wait_for_state() { + local def_state_timeout=5 + local subsys_name="$1" + local state="$2" + local timeout="${3:-$def_state_timeout}" + local nvmedev + local state_file + local start_time + local end_time + + nvmedev=$(_find_nvme_dev "${subsys_name}") + state_file="/sys/class/nvme-fabrics/ctl/${nvmedev}/state" + + start_time=$(date +%s) + while ! grep -q "${state}" "${state_file}"; do + sleep 1 + end_time=$(date +%s) + if (( end_time - start_time > timeout )); then + echo "expected state \"${state}\" not " \ + "reached within ${timeout} seconds" + return 1 + fi + done + + return 0 +} + +nvmet_reset_loop() { + while true; do + nvmet_debug_trigger_reset "${def_subsysnqn}" + sleep 2 + done +} + +test() { + echo "Running ${TEST_NAME}" + + _setup_nvmet + + _nvmet_target_setup + + nvmet_reset_loop & + fio_pid=$! + + # Try to trigger resets when the host is in different states connected, + # or connecting by calling target reset with an even number and the + # reconnect attempt with an uneven timeout. + for ((i = 0; i <= 5; i++)); do + _nvme_connect_subsys --keep-alive-tmo 1 --reconnect-delay 1 + sleep 3 + _nvme_disconnect_subsys >> "$FULL" 2>&1 + done + + { kill "${fio_pid}"; wait; } &> /dev/null + + _nvmet_target_cleanup + + echo "Test complete" +} diff --git a/tests/nvme/060.out b/tests/nvme/060.out new file mode 100644 index 0000000000000000000000000000000000000000..517ff2dfcfd41c4088991e669af9fef52bde570b --- /dev/null +++ b/tests/nvme/060.out @@ -0,0 +1,2 @@ +Running nvme/060 +Test complete
Newer kernel support to reset the target via the debugfs. Add a new test case which exercises this interface. Signed-off-by: Daniel Wagner <wagi@kernel.org> --- tests/nvme/060 | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/nvme/060.out | 2 ++ 2 files changed, 90 insertions(+)