diff mbox series

[blktests,05/11] nvme/rc: introduce NVMET_TR_TYPES

Message ID 20240411111228.2290407-6-shinichiro.kawasaki@wdc.com (mailing list archive)
State New, archived
Headers show
Series support test case repeat by different conditions | expand

Commit Message

Shinichiro Kawasaki April 11, 2024, 11:12 a.m. UTC
Some of the test cases in nvme test group can be run under various nvme
target transport types. The configuration parameter nvme_trtype
specifies the transport to use. But this configuration method has two
drawbacks. Firstly, the blktests check script needs to be invoked
multiple times to cover multiple transport types. Secondly, the test
cases irrelevant to the transport types are executed exactly same
conditions in the multiple blktests runs.

To avoid the drawbacks, introduce new configuration parameter
NVMET_TR_TYPES. This is an array, and multiple transport types can
be set like:

    NVMET_TR_TYPES=(loop tcp)

Also introduce _nvmet_set_nvme_trtype() which can be called from the
set_conditions() hook of the transport type dependent test cases.
Blktests will repeat the test case as many as the number of elements in
NVMET_TR_TYPES, and set nvme_trtype for each test case run.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
---
 Documentation/running-tests.md |  6 +++++-
 tests/nvme/rc                  | 30 +++++++++++++++++++++++++++++-
 2 files changed, 34 insertions(+), 2 deletions(-)

Comments

Daniel Wagner April 11, 2024, 6:41 p.m. UTC | #1
On Thu, Apr 11, 2024 at 08:12:22PM +0900, Shin'ichiro Kawasaki wrote:
> Some of the test cases in nvme test group can be run under various nvme
> target transport types. The configuration parameter nvme_trtype
> specifies the transport to use. But this configuration method has two
> drawbacks. Firstly, the blktests check script needs to be invoked
> multiple times to cover multiple transport types. Secondly, the test
> cases irrelevant to the transport types are executed exactly same
> conditions in the multiple blktests runs.
> 
> To avoid the drawbacks, introduce new configuration parameter
> NVMET_TR_TYPES. This is an array, and multiple transport types can
> be set like:
> 
>     NVMET_TR_TYPES=(loop tcp)
> 
> Also introduce _nvmet_set_nvme_trtype() which can be called from the
> set_conditions() hook of the transport type dependent test cases.
> Blktests will repeat the test case as many as the number of elements in
> NVMET_TR_TYPES, and set nvme_trtype for each test case run.

I suggest to keep the naming of the variable consistent, e.g.
NVMET_TRTYPES.
Shinichiro Kawasaki April 12, 2024, 10:56 a.m. UTC | #2
On Apr 11, 2024 / 20:41, Daniel Wagner wrote:
> On Thu, Apr 11, 2024 at 08:12:22PM +0900, Shin'ichiro Kawasaki wrote:
> > Some of the test cases in nvme test group can be run under various nvme
> > target transport types. The configuration parameter nvme_trtype
> > specifies the transport to use. But this configuration method has two
> > drawbacks. Firstly, the blktests check script needs to be invoked
> > multiple times to cover multiple transport types. Secondly, the test
> > cases irrelevant to the transport types are executed exactly same
> > conditions in the multiple blktests runs.
> > 
> > To avoid the drawbacks, introduce new configuration parameter
> > NVMET_TR_TYPES. This is an array, and multiple transport types can
> > be set like:
> > 
> >     NVMET_TR_TYPES=(loop tcp)
> > 
> > Also introduce _nvmet_set_nvme_trtype() which can be called from the
> > set_conditions() hook of the transport type dependent test cases.
> > Blktests will repeat the test case as many as the number of elements in
> > NVMET_TR_TYPES, and set nvme_trtype for each test case run.
> 
> I suggest to keep the naming of the variable consistent, e.g.
> NVMET_TRTYPES.

I see. I can think of NVME_TRTYPES and NVMET_TRTYPES, and I'm fine with
both. If there is no other voice, I will rename to NVMET_TRTYPES.
Shinichiro Kawasaki April 16, 2024, 5:20 a.m. UTC | #3
On Apr 11, 2024 / 20:12, Shin'ichiro Kawasaki wrote:
> Some of the test cases in nvme test group can be run under various nvme
> target transport types. The configuration parameter nvme_trtype
> specifies the transport to use. But this configuration method has two
> drawbacks. Firstly, the blktests check script needs to be invoked
> multiple times to cover multiple transport types. Secondly, the test
> cases irrelevant to the transport types are executed exactly same
> conditions in the multiple blktests runs.
> 
> To avoid the drawbacks, introduce new configuration parameter
> NVMET_TR_TYPES. This is an array, and multiple transport types can
> be set like:
> 
>     NVMET_TR_TYPES=(loop tcp)
> 
> Also introduce _nvmet_set_nvme_trtype() which can be called from the
> set_conditions() hook of the transport type dependent test cases.
> Blktests will repeat the test case as many as the number of elements in
> NVMET_TR_TYPES, and set nvme_trtype for each test case run.
> 
> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> ---
>  Documentation/running-tests.md |  6 +++++-
>  tests/nvme/rc                  | 30 +++++++++++++++++++++++++++++-
>  2 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/running-tests.md b/Documentation/running-tests.md
> index ae80860..ede3a81 100644
> --- a/Documentation/running-tests.md
> +++ b/Documentation/running-tests.md
> @@ -102,8 +102,12 @@ RUN_ZONED_TESTS=1
>  
>  The NVMe tests can be additionally parameterized via environment variables.
>  
> +- NVMET_TR_TYPES (array)
> +  Set up NVME target backends with the specified transport.
> +  Valid elements are 'loop', 'tcp', 'rdma' and 'fc'. Default value is '(loop)'.
>  - nvme_trtype: 'loop' (default), 'tcp', 'rdma' and 'fc'
> -  Run the tests with the given transport.
> +  Run the tests with the given transport. This parameter is still usable but
> +  replaced with NVMET_TR_TYPES. Use NVMET_TR_TYPES instead.

I noticed that nvme_trtype is still useful. nvmet_trtypes can be set in both in
the config file and the command line. But NVMET_TRTYPES can be set in the config
file only, because bash does not support setting arrays in the command line.

  # nvme_trtypes=rdma ./check nvme/006     ... works
  # NVMET_TRTYPES=(rdma) ./check nvme/006  ... does not work

I will modify the descriptions above in the v2 series to note that both
nvme_trtype and NVMET_TRTYPES are supported and usable.

>  - nvme_img_size: '1G' (default)
>    Run the tests with given image size in bytes. 'm', 'M', 'g'
>  	and 'G' postfix are supported.
> diff --git a/tests/nvme/rc b/tests/nvme/rc
> index 1f5ff44..df6bf77 100644
> --- a/tests/nvme/rc
> +++ b/tests/nvme/rc
> @@ -18,10 +18,38 @@ def_hostid="0f01fb42-9f7f-4856-b0b3-51e60b8de349"
>  def_hostnqn="nqn.2014-08.org.nvmexpress:uuid:${def_hostid}"
>  export def_subsysnqn="blktests-subsystem-1"
>  export def_subsys_uuid="91fdba0d-f87b-4c25-b80f-db7be1418b9e"
> -nvme_trtype=${nvme_trtype:-"loop"}
>  nvme_img_size=${nvme_img_size:-"1G"}
>  nvme_num_iter=${nvme_num_iter:-"1000"}
>  
> +# Check consistency of NVMET_TR_TYPES and nvme_trtype configurations.
> +# If neither is configured, set the default value.
> +first_call=${first_call:-1}
> +if ((first_call)); then
> +	if [[ -n $nvme_trtype ]]; then
> +		if [[ -n $NVMET_TR_TYPES ]]; then
> +			echo "Both nvme_trtype and NVMET_TR_TYPES are specified"
> +			exit 1
> +		fi
> +		NVMET_TR_TYPES=("$nvme_trtype")
> +	elif [[ -z ${NVMET_TR_TYPES[*]} ]]; then
> +		nvme_trtype="loop"
> +		NVMET_TR_TYPES=("$nvme_trtype")
> +	fi
> +	first_call=0
> +fi
> +
> +_set_nvme_trtype() {
> +	local index=$1
> +
> +	if [[ -z $index ]]; then
> +		echo ${#NVMET_TR_TYPES[@]}
> +		return
> +	fi
> +
> +	nvme_trtype=${NVMET_TR_TYPES[index]}
> +	COND_DESC="nvmet tr=${nvme_trtype}"
> +}
> +
>  # TMPDIR can not be referred out of test() or test_device() context. Instead of
>  # global variable def_flie_path, use this getter function.
>  _nvme_def_file_path() {
> -- 
> 2.44.0
>
Shinichiro Kawasaki April 16, 2024, 10:28 a.m. UTC | #4
On Apr 16, 2024 / 05:20, Shinichiro Kawasaki wrote:
> On Apr 11, 2024 / 20:12, Shin'ichiro Kawasaki wrote:
> > Some of the test cases in nvme test group can be run under various nvme
> > target transport types. The configuration parameter nvme_trtype
> > specifies the transport to use. But this configuration method has two
> > drawbacks. Firstly, the blktests check script needs to be invoked
> > multiple times to cover multiple transport types. Secondly, the test
> > cases irrelevant to the transport types are executed exactly same
> > conditions in the multiple blktests runs.
> > 
> > To avoid the drawbacks, introduce new configuration parameter
> > NVMET_TR_TYPES. This is an array, and multiple transport types can
> > be set like:
> > 
> >     NVMET_TR_TYPES=(loop tcp)
> > 
> > Also introduce _nvmet_set_nvme_trtype() which can be called from the
> > set_conditions() hook of the transport type dependent test cases.
> > Blktests will repeat the test case as many as the number of elements in
> > NVMET_TR_TYPES, and set nvme_trtype for each test case run.
> > 
> > Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> > ---
> >  Documentation/running-tests.md |  6 +++++-
> >  tests/nvme/rc                  | 30 +++++++++++++++++++++++++++++-
> >  2 files changed, 34 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/running-tests.md b/Documentation/running-tests.md
> > index ae80860..ede3a81 100644
> > --- a/Documentation/running-tests.md
> > +++ b/Documentation/running-tests.md
> > @@ -102,8 +102,12 @@ RUN_ZONED_TESTS=1
> >  
> >  The NVMe tests can be additionally parameterized via environment variables.
> >  
> > +- NVMET_TR_TYPES (array)
> > +  Set up NVME target backends with the specified transport.
> > +  Valid elements are 'loop', 'tcp', 'rdma' and 'fc'. Default value is '(loop)'.
> >  - nvme_trtype: 'loop' (default), 'tcp', 'rdma' and 'fc'
> > -  Run the tests with the given transport.
> > +  Run the tests with the given transport. This parameter is still usable but
> > +  replaced with NVMET_TR_TYPES. Use NVMET_TR_TYPES instead.
> 
> I noticed that nvme_trtype is still useful. nvmet_trtypes can be set in both in
> the config file and the command line. But NVMET_TRTYPES can be set in the config
> file only, because bash does not support setting arrays in the command line.
> 
>   # nvme_trtypes=rdma ./check nvme/006     ... works
>   # NVMET_TRTYPES=(rdma) ./check nvme/006  ... does not work
> 
> I will modify the descriptions above in the v2 series to note that both
> nvme_trtype and NVMET_TRTYPES are supported and usable.

I rethought this. Now I think it is bad that NVMET_TRTYPES can not be specified
in command lines. To avoid this drawback, I think it's the better to change
NVME_TRTYPES from an array to a variable with multiple items separated with
spaces. For example, three types can be specified to NVMET_TRTYPES like this:

   NVMET_TRTYPES="loop tcp rdma"

NVMET_BLKDEV_TYPES has the same restriction then I will change it also from an
array to a variable in same manner. I will send out v2 soon with this change.

Daniel,

I assume this change is fine for your use case. If it is not the case, please
let me know.
Daniel Wagner April 16, 2024, 4:23 p.m. UTC | #5
On Tue, Apr 16, 2024 at 10:28:49AM +0000, Shinichiro Kawasaki wrote:
> >   # nvme_trtypes=rdma ./check nvme/006     ... works
> >   # NVMET_TRTYPES=(rdma) ./check nvme/006  ... does not work
> > 
> > I will modify the descriptions above in the v2 series to note that both
> > nvme_trtype and NVMET_TRTYPES are supported and usable.
> 
> I rethought this. Now I think it is bad that NVMET_TRTYPES can not be specified
> in command lines. To avoid this drawback, I think it's the better to change
> NVME_TRTYPES from an array to a variable with multiple items separated with
> spaces. For example, three types can be specified to NVMET_TRTYPES like this:
> 
>    NVMET_TRTYPES="loop tcp rdma"
> 
> NVMET_BLKDEV_TYPES has the same restriction then I will change it also from an
> array to a variable in same manner. I will send out v2 soon with this change.
> 
> Daniel,
> 
> I assume this change is fine for your use case. If it is not the case, please
> let me know.

Yes, it's nice that all the configure variables are of the same type.

On this topic, I am a bit confused about the naming scheme. We have the
lower case ones, e.g. 'nvme_trtypes' and now the upper case ones
NVMET_TRYPES. I assume you prefer the upper case to mark them they are
injected from the environment and the lower case ones are globals
variables in the framework. Should we retire the lower case ones and
replace them with upper case ones?
Chaitanya Kulkarni April 16, 2024, 6:43 p.m. UTC | #6
On 4/16/2024 9:23 AM, Daniel Wagner wrote:
> On Tue, Apr 16, 2024 at 10:28:49AM +0000, Shinichiro Kawasaki wrote:
>>>    # nvme_trtypes=rdma ./check nvme/006     ... works
>>>    # NVMET_TRTYPES=(rdma) ./check nvme/006  ... does not work
>>>
>>> I will modify the descriptions above in the v2 series to note that both
>>> nvme_trtype and NVMET_TRTYPES are supported and usable.
>>
>> I rethought this. Now I think it is bad that NVMET_TRTYPES can not be specified
>> in command lines. To avoid this drawback, I think it's the better to change
>> NVME_TRTYPES from an array to a variable with multiple items separated with
>> spaces. For example, three types can be specified to NVMET_TRTYPES like this:
>>
>>     NVMET_TRTYPES="loop tcp rdma"
>>
>> NVMET_BLKDEV_TYPES has the same restriction then I will change it also from an
>> array to a variable in same manner. I will send out v2 soon with this change.
>>
>> Daniel,
>>
>> I assume this change is fine for your use case. If it is not the case, please
>> let me know.
> 
> Yes, it's nice that all the configure variables are of the same type.
> 
> On this topic, I am a bit confused about the naming scheme. We have the
> lower case ones, e.g. 'nvme_trtypes' and now the upper case ones
> NVMET_TRYPES. I assume you prefer the upper case to mark them they are
> injected from the environment and the lower case ones are globals
> variables in the framework. Should we retire the lower case ones and
> replace them with upper case ones?

can we please keep the small letter similar to nvme_trtype ?

-ck
Shinichiro Kawasaki April 17, 2024, 12:58 a.m. UTC | #7
On Apr 16, 2024 / 18:43, Chaitanya Kulkarni wrote:
> On 4/16/2024 9:23 AM, Daniel Wagner wrote:
> > On Tue, Apr 16, 2024 at 10:28:49AM +0000, Shinichiro Kawasaki wrote:
> >>>    # nvme_trtypes=rdma ./check nvme/006     ... works
> >>>    # NVMET_TRTYPES=(rdma) ./check nvme/006  ... does not work
> >>>
> >>> I will modify the descriptions above in the v2 series to note that both
> >>> nvme_trtype and NVMET_TRTYPES are supported and usable.
> >>
> >> I rethought this. Now I think it is bad that NVMET_TRTYPES can not be specified
> >> in command lines. To avoid this drawback, I think it's the better to change
> >> NVME_TRTYPES from an array to a variable with multiple items separated with
> >> spaces. For example, three types can be specified to NVMET_TRTYPES like this:
> >>
> >>     NVMET_TRTYPES="loop tcp rdma"
> >>
> >> NVMET_BLKDEV_TYPES has the same restriction then I will change it also from an
> >> array to a variable in same manner. I will send out v2 soon with this change.
> >>
> >> Daniel,
> >>
> >> I assume this change is fine for your use case. If it is not the case, please
> >> let me know.
> > 
> > Yes, it's nice that all the configure variables are of the same type.
> > 
> > On this topic, I am a bit confused about the naming scheme. We have the
> > lower case ones, e.g. 'nvme_trtypes' and now the upper case ones
> > NVMET_TRYPES. I assume you prefer the upper case to mark them they are
> > injected from the environment and the lower case ones are globals
> > variables in the framework. Should we retire the lower case ones and
> > replace them with upper case ones?

Yes, "mark them they are injected from the environment" was the one reason to
have the parameters in upper cases. The other reason was the consistency across
the all parameters described in Documentation/running-tests.md.

> 
> can we please keep the small letter similar to nvme_trtype ?

I'm fine to have small letter, lower cases for the new parameter, but I would
like to clarify the reason to have lower cases. Do you mean to indicate that
"the parameters are test group local" using the lower cases?
Daniel Wagner April 17, 2024, 6:06 a.m. UTC | #8
On Wed, Apr 17, 2024 at 12:58:53AM +0000, Shinichiro Kawasaki wrote:
> Yes, "mark them they are injected from the environment" was the one reason to
> have the parameters in upper cases. The other reason was the consistency across
> the all parameters described in Documentation/running-tests.md.
> 
> > can we please keep the small letter similar to nvme_trtype ?
> 
> I'm fine to have small letter, lower cases for the new parameter, but I would
> like to clarify the reason to have lower cases. Do you mean to indicate that
> "the parameters are test group local" using the lower cases?

Lower cased environment variables are not very common, in fact
POSIX.1-2017 mandates upper cased environment variables [1]. Also only
the nvme part of the framework is using the lower case ones, thus I
agree with Shinichiro to streamline these nvme variables to upper cased
versions.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
Chaitanya Kulkarni April 18, 2024, 6:12 a.m. UTC | #9
On 4/16/24 23:06, Daniel Wagner wrote:
> On Wed, Apr 17, 2024 at 12:58:53AM +0000, Shinichiro Kawasaki wrote:
>> Yes, "mark them they are injected from the environment" was the one reason to
>> have the parameters in upper cases. The other reason was the consistency across
>> the all parameters described in Documentation/running-tests.md.
>>
>>> can we please keep the small letter similar to nvme_trtype ?
>> I'm fine to have small letter, lower cases for the new parameter, but I would
>> like to clarify the reason to have lower cases. Do you mean to indicate that
>> "the parameters are test group local" using the lower cases?

what I meant that for nvme we have lowecase global variables, in case
we add new upper case variables they will create confusion ...

> Lower cased environment variables are not very common, in fact
> POSIX.1-2017 mandates upper cased environment variables [1]. Also only
> the nvme part of the framework is using the lower case ones, thus I
> agree with Shinichiro to streamline these nvme variables to upper cased
> versions.
>
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

agree they should be uppercase not denying that, the only reason I
asked since existing variables are lowercase, it'd be very confusing
to have some variables in nvme category with lower case and some
upper case ...

-ck
Daniel Wagner April 18, 2024, 6:36 a.m. UTC | #10
On Thu, Apr 18, 2024 at 06:12:40AM +0000, Chaitanya Kulkarni wrote:
> agree they should be uppercase not denying that, the only reason I
> asked since existing variables are lowercase, it'd be very confusing
> to have some variables in nvme category with lower case and some
> upper case ...

Same here, so let's fix this and add upper case versions of the existing
variables incl documentation. I suggest we keep the lower case ones
around for awhile (maybe incl a warning?) before we drop the support.

What do you think?
Chaitanya Kulkarni April 18, 2024, 7:18 a.m. UTC | #11
On 4/17/24 23:36, Daniel Wagner wrote:
> On Thu, Apr 18, 2024 at 06:12:40AM +0000, Chaitanya Kulkarni wrote:
>> agree they should be uppercase not denying that, the only reason I
>> asked since existing variables are lowercase, it'd be very confusing
>> to have some variables in nvme category with lower case and some
>> upper case ...
> Same here, so let's fix this and add upper case versions of the existing
> variables incl documentation. I suggest we keep the lower case ones
> around for awhile (maybe incl a warning?) before we drop the support.
>
> What do you think?

that should work but let's be very careful about removing lowercase
options since it might break bunch of setups ....

-ck
Shinichiro Kawasaki April 24, 2024, 8:55 a.m. UTC | #12
On Apr 18, 2024 / 07:18, Chaitanya Kulkarni wrote:
> On 4/17/24 23:36, Daniel Wagner wrote:
> > On Thu, Apr 18, 2024 at 06:12:40AM +0000, Chaitanya Kulkarni wrote:
> >> agree they should be uppercase not denying that, the only reason I
> >> asked since existing variables are lowercase, it'd be very confusing
> >> to have some variables in nvme category with lower case and some
> >> upper case ...
> > Same here, so let's fix this and add upper case versions of the existing
> > variables incl documentation. I suggest we keep the lower case ones
> > around for awhile (maybe incl a warning?) before we drop the support.
> >
> > What do you think?
> 
> that should work but let's be very careful about removing lowercase
> options since it might break bunch of setups ....

I agree with this approach. I've just sent out v3 to which I added the patches
to introduce the uppercase options below:

  nvme_img_size -> NVME_IMG_SIZE
  nvme_num_iter -> NVME_NUM_ITER
  use_rxe -> USE_RXE

Both uppercase and lowercase options will work, but it is guided to use the
uppercase option.
diff mbox series

Patch

diff --git a/Documentation/running-tests.md b/Documentation/running-tests.md
index ae80860..ede3a81 100644
--- a/Documentation/running-tests.md
+++ b/Documentation/running-tests.md
@@ -102,8 +102,12 @@  RUN_ZONED_TESTS=1
 
 The NVMe tests can be additionally parameterized via environment variables.
 
+- NVMET_TR_TYPES (array)
+  Set up NVME target backends with the specified transport.
+  Valid elements are 'loop', 'tcp', 'rdma' and 'fc'. Default value is '(loop)'.
 - nvme_trtype: 'loop' (default), 'tcp', 'rdma' and 'fc'
-  Run the tests with the given transport.
+  Run the tests with the given transport. This parameter is still usable but
+  replaced with NVMET_TR_TYPES. Use NVMET_TR_TYPES instead.
 - nvme_img_size: '1G' (default)
   Run the tests with given image size in bytes. 'm', 'M', 'g'
 	and 'G' postfix are supported.
diff --git a/tests/nvme/rc b/tests/nvme/rc
index 1f5ff44..df6bf77 100644
--- a/tests/nvme/rc
+++ b/tests/nvme/rc
@@ -18,10 +18,38 @@  def_hostid="0f01fb42-9f7f-4856-b0b3-51e60b8de349"
 def_hostnqn="nqn.2014-08.org.nvmexpress:uuid:${def_hostid}"
 export def_subsysnqn="blktests-subsystem-1"
 export def_subsys_uuid="91fdba0d-f87b-4c25-b80f-db7be1418b9e"
-nvme_trtype=${nvme_trtype:-"loop"}
 nvme_img_size=${nvme_img_size:-"1G"}
 nvme_num_iter=${nvme_num_iter:-"1000"}
 
+# Check consistency of NVMET_TR_TYPES and nvme_trtype configurations.
+# If neither is configured, set the default value.
+first_call=${first_call:-1}
+if ((first_call)); then
+	if [[ -n $nvme_trtype ]]; then
+		if [[ -n $NVMET_TR_TYPES ]]; then
+			echo "Both nvme_trtype and NVMET_TR_TYPES are specified"
+			exit 1
+		fi
+		NVMET_TR_TYPES=("$nvme_trtype")
+	elif [[ -z ${NVMET_TR_TYPES[*]} ]]; then
+		nvme_trtype="loop"
+		NVMET_TR_TYPES=("$nvme_trtype")
+	fi
+	first_call=0
+fi
+
+_set_nvme_trtype() {
+	local index=$1
+
+	if [[ -z $index ]]; then
+		echo ${#NVMET_TR_TYPES[@]}
+		return
+	fi
+
+	nvme_trtype=${NVMET_TR_TYPES[index]}
+	COND_DESC="nvmet tr=${nvme_trtype}"
+}
+
 # TMPDIR can not be referred out of test() or test_device() context. Instead of
 # global variable def_flie_path, use this getter function.
 _nvme_def_file_path() {