From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F6DF42A83 for ; Wed, 7 May 2025 18:50:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746643818; cv=none; b=hnpFFDb2fnb4i/rF038TB0r88/fnpbvjeSBeAtPchVov+PUEAOkRVq7+MS8XqY517ETunpT1HNNFQ5EPMPSpLEINEy4I6MvzaerSfBdnXMk77DSiwwz1tucf+9TpPFohKCnC66VvT6FrLtQL+cWsGwfHls+dyRLrqlfYFWzONys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746643818; c=relaxed/simple; bh=kHskeEukDImSLmqUz6QAY0YM2wUv1dhlgb5ZHLDXoeM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fWebukjmyOINM35L0SmPYEd8RREztyv61kwlo5G9VO7dPpYe0+LdtEvBiLxTX1Q0dU/kV4FFzN/l7S3RHqv+QBiyQCI3oabi0QP73L5/zw9iwkd6qPM/jw8G7lUFsIApiU2RPOlMhFWtwhOlzXDcxixD7X3lEw0wiuLCbiE1Ko0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fCv6gHZc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fCv6gHZc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4742FC4CEEF; Wed, 7 May 2025 18:50:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746643817; bh=kHskeEukDImSLmqUz6QAY0YM2wUv1dhlgb5ZHLDXoeM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fCv6gHZc/1RDEMr7an7prynvGSKo/A2moOWJ7pAGNPSXgxwwj4hR95LBG6aydXyZg vC7J1T3frAb7nIOE1P5SC+zXWAw+ftX6cvl5/w2CLrFS3t5sIsk42uIZMI/U7GBnWi wnTmxnB73gBzQK24jBt9SluwKfeagPOK74sxGvdDH6oKalpALY3bumEvcW/W14NGRq TMlITq+JtDgneZwfm6X/cwrlT4zzUFOQ8T2jSdjWbeOGKfxZLF3LQ2pfnQo/qcH1Wc ue1DDUGWhwXPQEWMDhkbL+Zcy7/CJcW1NTHuhNpeARvtF/QEkMgG26LUazn/WMSkvE 9KVk2/nAa9u1Q== Date: Wed, 7 May 2025 11:50:15 -0700 From: Luis Chamberlain To: Daniel Gomez Cc: Klaus Jensen , kdevops@lists.linux.dev, Daniel Gomez Subject: Re: [PATCH] libvirt: update default extra storage drive Message-ID: References: <20250506-libvirt-default-extra-storage-fixes-v1-1-3eb5c3544af4@samsung.com> <2nv36pylldtj74xyqp4mdodw4aek2r6l7uie25ecmli45o24wy@fs47gipere2j> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2nv36pylldtj74xyqp4mdodw4aek2r6l7uie25ecmli45o24wy@fs47gipere2j> On Wed, May 07, 2025 at 12:19:26PM +0200, Daniel Gomez wrote: > On Tue, May 06, 2025 at 01:23:42PM +0100, Luis Chamberlain wrote: > > On Tue, May 06, 2025 at 11:18:28AM +0200, Daniel Gomez wrote: > > > From: Daniel Gomez > > > > > > kdevops expects NVMe to be selected as stated in the config. > > > > In which config? > > It's part of the help here "We always expect to use...": > > config LIBVIRT_EXTRA_STORAGE_DRIVE_NVME > bool "NVMe" > output yaml > help > Use the QEMU NVMe driver for extra storage drives. We always expect > to use this as we expect *could* be outperforming the virtio driver. Ah yeah that's outdated. > > So, the history here was that through experience on a lot of testing > > (specially the stable folks) they experienced *tons* of NVMe timeouts > > as flaky failure tests. Part of this was root caused to the slow > > performant qemu NVMe driver since it lacked using qemu IO threads, which > > allows the device to perform I/O in its own thread rather than in the > > main QEMU thread. Virtio already has support IO threads, so as soon as we > > switched to virtio that fixed the issues. > > config LIBVIRT_EXTRA_STORAGE_DRIVE_VIRTIO > bool "virtio" > output yaml > help > Use the QEMU virtio driver for extra storage drives. Use this if you > are having issues with "NVMe timeouts" issues when testing in a loop > with fstests and cannot upgrade your QEMU version. If you select this > you won't be able to test ZNS. > > I read the help the other way around as you have just described it. I think text > needs an update then. Indeed. > > Yes, it would be good to make NVMe the default backend storage driver > > but if default qemu release on distros don't yet have IO thread support > > then it makes no sense to switch over, sadly. > > I understand. > > The problem was found when I run blktests with block and nvme profiles > where an NVMe drive was expected in the vm. Would then a 'select > LIBVIRT_EXTRA_SOTRAGE_DRIVE_NVME' work for blktests in this case? So blktests can be used in two modes, one without specifying any devices, and one with it. If you don't specify any device it uses loopback frabics to create loopback nvme drives to then test nvme. So I'd say testing against both would be good, but either works. Luis