[PATCH blktests v3 1/3] nvme/rc: introduce remote target support

Daniel Wagner dwagner at suse.de
Thu Jun 27 03:23:44 PDT 2024


On Thu, Jun 27, 2024 at 11:59:11AM GMT, Hannes Reinecke wrote:
 > +	if [[ -n "${nvme_target_control}" ]]; then
> > +		eval "${nvme_target_control}" cleanup \
> > +			--subsysnqn "${subsysnqn}" \
> > +			> /dev/null
> > +		return
> > +	fi
> > +
> >   	_get_nvmet_ports "${subsysnqn}" ports
> >   	for port in "${ports[@]}"; do
> 
> Hmm. This wasn't quite what I had in mind; I think it'd be simpler
> if we could just check if the requested controller is visible to the
> host already (ie checking sysfs here), and then skip all the setup
> steps at they are obviously not required anymore.
> That would save quite a lot of issues, and we wouldn't need to specify
> a target setup script (or whatever).

What I like at the current approach is that it allows to support the
use case where the external target can be configured. For example this
works with a remote VM running Linux pretty well. With your idea only
static setups are supported.

I don't know what you mean with 'quite a lot of issues'. I've running
this against a VM which gets dynamically configured and it works well.

> Quite a bit of churn, I agree, as that would mean we have to roll
>
> 	_setup_nvmet
>
> 	_nvmet_target_setup
>
> 	_nvme_connect_subsys
>
> all into one function. But it might be easier in the long run.
> Hmm?

Not all tests have this pattern, e.g. nvme/031. This test works with
the approach in the version of the series though.

Sure, I'll don't see a problem to refactor a bit more and reduce the
boiler plate even more but I see this a different task.



More information about the Linux-nvme mailing list