mbox series

[blktests,v2,00/12] Switch to allowed_host

Message ID 20230810111317.25273-1-dwagner@suse.de (mailing list archive)
Headers show
Series Switch to allowed_host | expand

Message

Daniel Wagner Aug. 10, 2023, 11:13 a.m. UTC
I've updated the series accoring the feedback. Also added the mentioned
_nvmet_target_{setup|cleanup} helpers which reduced a lot of code.
Roughly 350 lines code less after the refactoring.

Maybe it's possible to refactor even more, e.g. this snippet


	local nvmedev
	nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
	cat "/sys/block/${nvmedev}n1/uuid"
	cat "/sys/block/${nvmedev}n1/wwid"

could be moved into _nvme_connect_subsys(). Though there are quiet a few tests
which want the nvmedev later on for something like

	_run_fio_verify_io --size="${nvme_img_size}" \
		--filename="/dev/${nvmedev}n1"

So we could return the nvmedev from _nvme_connect_subsys() but I don't know if
this a good idea. FWIW, it would also fix the current problem we face with
nvme/047 which seems to lack the second _find_nvme_dev() call.


original cover letter:

Max asked me to replace replace the 'nvme/rc: Avoid triggering host nvme-cli
autoconnect' feature with using allowed_host on the target side [1]

So while looking into this new feature, I first started to refactor existing
code so that it looks a bit more consistent. I think there is even more
potential to make it smaller, by introducing something similiar to
_nvmet_passthru_target_setup() and _nvmet_passthru_target_cleanup() for non
passthru tests. A lot of duplicated setup/cleanup code in many tests.

Except the last two patches are just refactoring patches. So if we decide to use
common target setup/cleanup helpers, I think we could add them before the last
two patches, which would make the last patch way smaller.

Daniel

[1] https://lore.kernel.org/all/4b17be94-d068-f026-756f-59208075e254@nvidia.com/

changes:
v2:
 - updated commit messages
 - moved the removal of subsys_name to the right patch
 - added _nvmet_target_{setup|cleanup} helpers
   this addresses also the 'appears unused' warning by ShellCheck

v1:
 - initial version
   https://lore.kernel.org/linux-nvme/20230726124644.12619-1-dwagner@suse.de/

Daniel Wagner (12):
  nvme/{003,004,005,013,046,049}: Group all variables declarations
  nvme: Reorganize test preamble code section
  nvme/rc: Add common subsystem nqn define
  nvme: Use def_subsysnqn variable instead local variable
  nvme/{041,042,043,044,045,048}: Remove local variable hostnqn and
    hostid
  nvme/rc: Add common file_path name define
  nvme: Use def_file_path variable instead local variable
  nvme/rc: Add common def_subsys_uuid define
  nvme: Use def_subsys_uuid variable
  nvme/rc: Add helper for adding/removing to allow list
  nvme: Add explicitly host to allow_host list
  nvme: Introduce nvmet_target_{setup/cleanup} common code

 tests/nvme/003 | 12 ++-----
 tests/nvme/004 | 23 ++++---------
 tests/nvme/005 | 22 +++---------
 tests/nvme/006 | 21 ++----------
 tests/nvme/007 | 19 ++---------
 tests/nvme/008 | 26 +++------------
 tests/nvme/009 | 21 +++---------
 tests/nvme/010 | 26 +++------------
 tests/nvme/011 | 22 +++---------
 tests/nvme/012 | 26 +++------------
 tests/nvme/013 | 22 +++---------
 tests/nvme/014 | 26 +++------------
 tests/nvme/015 | 21 +++---------
 tests/nvme/016 | 17 +++++-----
 tests/nvme/017 | 26 ++++++---------
 tests/nvme/018 | 21 +++---------
 tests/nvme/019 | 26 +++------------
 tests/nvme/020 | 21 +++---------
 tests/nvme/021 | 21 +++---------
 tests/nvme/022 | 21 +++---------
 tests/nvme/023 | 26 +++------------
 tests/nvme/024 | 21 +++---------
 tests/nvme/025 | 21 +++---------
 tests/nvme/026 | 21 +++---------
 tests/nvme/027 | 20 +++--------
 tests/nvme/028 | 20 +++--------
 tests/nvme/029 | 26 +++------------
 tests/nvme/030 | 19 ++++++-----
 tests/nvme/031 | 14 ++++----
 tests/nvme/033 |  9 ++---
 tests/nvme/034 |  9 ++---
 tests/nvme/035 |  9 ++---
 tests/nvme/036 |  9 ++---
 tests/nvme/037 |  8 ++---
 tests/nvme/038 |  6 ++--
 tests/nvme/039 |  4 +--
 tests/nvme/040 | 28 +++++-----------
 tests/nvme/041 | 49 +++++++++------------------
 tests/nvme/042 | 55 ++++++++++--------------------
 tests/nvme/043 | 52 ++++++++++-------------------
 tests/nvme/044 | 71 +++++++++++++++------------------------
 tests/nvme/045 | 62 ++++++++++++----------------------
 tests/nvme/046 |  1 +
 tests/nvme/047 | 30 ++++-------------
 tests/nvme/048 | 42 +++++++----------------
 tests/nvme/049 |  1 +
 tests/nvme/rc  | 90 +++++++++++++++++++++++++++++++++++++++++++++++---
 47 files changed, 398 insertions(+), 765 deletions(-)

Comments

Shin'ichiro Kawasaki Aug. 11, 2023, 6:16 a.m. UTC | #1
On Aug 10, 2023 / 13:13, Daniel Wagner wrote:
> I've updated the series accoring the feedback. Also added the mentioned
> _nvmet_target_{setup|cleanup} helpers which reduced a lot of code.
> Roughly 350 lines code less after the refactoring.
> 
> Maybe it's possible to refactor even more, e.g. this snippet
> 
> 
> 	local nvmedev
> 	nvmedev=$(_find_nvme_dev "${def_subsysnqn}")
> 	cat "/sys/block/${nvmedev}n1/uuid"
> 	cat "/sys/block/${nvmedev}n1/wwid"
> 
> could be moved into _nvme_connect_subsys(). Though there are quiet a few tests
> which want the nvmedev later on for something like
> 
> 	_run_fio_verify_io --size="${nvme_img_size}" \
> 		--filename="/dev/${nvmedev}n1"
> 
> So we could return the nvmedev from _nvme_connect_subsys() but I don't know if
> this a good idea.

IMO, it is a good idea to make _nvme_connect_subsys() return the device. The
similar function _nvmet_passthru_target_connect() does that, so it is another
small goodness to have consistency between the two.

> FWIW, it would also fix the current problem we face with
> nvme/047 which seems to lack the second _find_nvme_dev() call.

I posted the fix patch for the nvme/047 problem reflecting your comments. I hope
that fix settled before further refactoring.

It is a fun to see the much of the boiler plates go away with the series :)
Thanks. I provided two minor comments on the 5th patch and 10th patch. Other
than that, this series looks good to me. Also I did another trial run, and
saw no regression. Good.
Daniel Wagner Aug. 11, 2023, 7 a.m. UTC | #2
On Fri, Aug 11, 2023 at 06:16:45AM +0000, Shinichiro Kawasaki wrote:
> > So we could return the nvmedev from _nvme_connect_subsys() but I don't know if
> > this a good idea.
> 
> IMO, it is a good idea to make _nvme_connect_subsys() return the device. The
> similar function _nvmet_passthru_target_connect() does that, so it is another
> small goodness to have consistency between the two.

Sure, I'll look into this when I remove the udev trigger filter code
again which resulted in this series. But let's get this series sorted
out first.

> > FWIW, it would also fix the current problem we face with
> > nvme/047 which seems to lack the second _find_nvme_dev() call.
> 
> I posted the fix patch for the nvme/047 problem reflecting your comments. I hope
> that fix settled before further refactoring.

Yep, let's get the bug fix in first.

> It is a fun to see the much of the boiler plates go away with the
> series :)

Ineed, makes the test way smaller.

BTW, what do you think about removing nvme/006 and nvme/007? They are
basically doing nothing anymore except setting up a target with either
device or file backing. We exercise this code now in all the other
tests. So this is bit redundant IMO.

> Thanks. I provided two minor comments on the 5th patch and 10th patch. Other
> than that, this series looks good to me. Also I did another trial run, and
> saw no regression. Good.

I've updated the series accordingly. Let me run a quick test and then I
post the update.
Shin'ichiro Kawasaki Aug. 17, 2023, 2:55 a.m. UTC | #3
On Aug 11, 2023 / 09:00, Daniel Wagner wrote:
[...]
> BTW, what do you think about removing nvme/006 and nvme/007? They are
> basically doing nothing anymore except setting up a target with either
> device or file backing. We exercise this code now in all the other
> tests. So this is bit redundant IMO.

I think the test cases are meaningful. They confirm that target set up feature
is working good. When other test cases fail, we can refer nvme/006 and nvme/007
results and see if the failure cause is in target set up or not.
Daniel Wagner Aug. 17, 2023, 8:22 a.m. UTC | #4
On Thu, Aug 17, 2023 at 02:55:25AM +0000, Shinichiro Kawasaki wrote:
> On Aug 11, 2023 / 09:00, Daniel Wagner wrote:
> [...]
> > BTW, what do you think about removing nvme/006 and nvme/007? They are
> > basically doing nothing anymore except setting up a target with either
> > device or file backing. We exercise this code now in all the other
> > tests. So this is bit redundant IMO.
> 
> I think the test cases are meaningful. They confirm that target set up feature
> is working good. When other test cases fail, we can refer nvme/006 and nvme/007
> results and see if the failure cause is in target set up or not.

Fair enough. If I want to cut execution time I can just exclude those
test from the run.