From: "Javier González" <javier@javigon.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Keith Busch <kbusch@kernel.org>,
Adam Manzanares <a.manzanares@samsung.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>,
"msnitzer@redhat.com >> msnitzer@redhat.com"
<msnitzer@redhat.com>, Bart Van Assche <bvanassche@acm.org>,
"martin.petersen@oracle.com >> Martin K. Petersen"
<martin.petersen@oracle.com>,
"roland@purestorage.com" <roland@purestorage.com>,
Hannes Reinecke <hare@suse.de>, Christoph Hellwig <hch@lst.de>,
"Frederick.Knight@netapp.com" <Frederick.Knight@netapp.com>,
"zach.brown@ni.com" <zach.brown@ni.com>,
"osandov@fb.com" <osandov@fb.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"djwong@kernel.org" <djwong@kernel.org>,
"josef@toxicpanda.com" <josef@toxicpanda.com>,
"clm@fb.com" <clm@fb.com>, "dsterba@suse.com" <dsterba@suse.com>,
"tytso@mit.edu" <tytso@mit.edu>, "jack@suse.com" <jack@suse.com>,
Kanchan Joshi <joshi.k@samsung.com>
Subject: Re: [RFC PATCH 3/3] nvme: add the "debug" host driver
Date: Fri, 4 Feb 2022 12:34:23 +0100 [thread overview]
Message-ID: <20220204113423.jmynvz4w5u6wdban@ArmHalley.local> (raw)
In-Reply-To: <4d5410a5-93c3-d73c-6aeb-2c1c7f940963@nvidia.com>
On 04.02.2022 09:58, Chaitanya Kulkarni wrote:
>On 2/4/22 12:24 AM, Javier González wrote:
>> On 04.02.2022 07:58, Chaitanya Kulkarni wrote:
>>> On 2/3/22 22:28, Damien Le Moal wrote:
>>>> On 2/4/22 12:12, Chaitanya Kulkarni wrote:
>>>>>
>>>>>>>> One can instantiate scsi devices with qemu by using fake scsi
>>>>>>>> devices,
>>>>>>>> but one can also just use scsi_debug to do the same. I see both
>>>>>>>> efforts
>>>>>>>> as desirable, so long as someone mantains this.
>>>>>>>>
>>>>>
>>>>> Why do you think both efforts are desirable ?
>>>>
>>>> When testing code using the functionality, it is far easier to get said
>>>> functionality doing a simple "modprobe" rather than having to setup a
>>>> VM. C.f. running blktests or fstests.
>>>>
>>>
>>> agree on simplicity but then why do we have QEMU implementations for
>>> the NVMe features (e.g. ZNS, NVMe Simple Copy) ? we can just build
>>> memoery backed NVMeOF test target for NVMe controller features.
>>>
>>> Also, recognizing the simplicity I proposed initially NVMe ZNS
>>> fabrics based emulation over QEMU (I think I still have initial state
>>> machine implementation code for ZNS somewhere), those were "nacked" for
>>> the right reason, since we've decided go with QEMU and use that as a
>>> primary platform for testing, so I failed to understand what has
>>> changed.. since given that QEMU already supports NVMe simple copy ...
>>
>> I was not part of this conversation, but as I see it each approach give
>> a benefit. QEMU is fantastic for compliance testing and I am not sure
>> you get the same level of command analysis anywhere else; at least not
>> without writing dedicated code for this in a target.
>>
>> This said, when we want to test for race conditions, QEMU is very slow.
>
>Can you please elaborate the scenario and numbers for slowness of QEMU?
QEMU is an emulator, not a simulator. So we will not be able to stress
the host stack in the same way the null_blk device does. If we want to
test code in the NVMe driver then we need a way to have the equivalent
to the null_blk in NVMe. It seems like the nvme-loop target can achieve
this.
Does this answer your concern?
>
>For race conditions testing we can build error injection framework
>around the code implementation which present in kernel everywhere.
True. This is also a good way to do this.
>
>> For a software-only solution, we have experimented with something
>> similar to the nvme-debug code tha Mikulas is proposing. Adam pointed to
>> the nvme-loop target as an alternative and this seems to work pretty
>> nicely. I do not believe there should be many changes to support copy
>> offload using this.
>>
>
>If QEMU is so incompetent then we need to add every big feature into
>the NVMeOF test target so that we can test it better ? is that what
>you are proposing ? since if we implement one feature, it will be
>hard to nack any new features that ppl will come up with
>same rationale "with QEMU being slow and hard to test race
>conditions etc .."
In my opinion, if people want this and is willing to maintain it, there
is a case for it.
>
>and if that is the case why we don't have ZNS NVMeOF target
>memory backed emulation ? Isn't that a bigger and more
>complicated feature than Simple Copy where controller states
>are involved with AENs ?
I think this is a good idea.
>
>ZNS kernel code testing is also done on QEMU, I've also fixed
>bugs in the ZNS kernel code which are discovered on QEMU and I've not
>seen any issues with that. Given that simple copy feature is way smaller
>than ZNS it will less likely to suffer from slowness and etc (listed
>above) in QEMU.
QEMU is super useful: it is easy and it help identifying many issues.
But it is for compliance, not for performance. There was an effort to
make FEMU, but this seems to be an abandoned project.
>
>my point is if we allow one, we will be opening floodgates and we need
>to be careful not to bloat the code unless it is _absolutely
>necessary_ which I don't think it is based on the simple copy
>specification.
I understand, and this is a very valid point. It seems like the
nvme-loop device can give a lot of what we need; all the necessary extra
logic can go into the null_blk and then we do not need NVMe specific
code.
Do you see any inconvenient with this approach?
>
>> So in my view having both is not replication and it gives more
>> flexibility for validation, which I believe it is always good.
>>
>
next prev parent reply other threads:[~2022-02-04 11:34 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220127071544uscas1p2f70f4d2509f3ebd574b7ed746d3fa551@uscas1p2.samsung.com>
2022-01-27 7:14 ` [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload Chaitanya Kulkarni
2022-01-28 19:59 ` Adam Manzanares
2022-01-31 11:49 ` Johannes Thumshirn
2022-01-31 19:03 ` Bart Van Assche
2022-02-01 1:54 ` Luis Chamberlain
2022-02-01 10:21 ` Javier González
2022-02-01 18:31 ` [RFC PATCH 0/3] NVMe copy offload patches Mikulas Patocka
2022-02-01 18:32 ` [RFC PATCH 1/3] block: add copy offload support Mikulas Patocka
2022-02-01 19:18 ` Bart Van Assche
2022-02-03 18:50 ` Mikulas Patocka
2022-02-03 20:11 ` Keith Busch
2022-02-03 22:49 ` Bart Van Assche
2022-02-04 12:09 ` Mikulas Patocka
2022-02-04 13:34 ` Jens Axboe
2022-02-02 16:21 ` Keith Busch
2022-02-02 16:40 ` Mikulas Patocka
2022-02-02 18:40 ` Knight, Frederick
2022-02-01 18:33 ` [RFC PATCH 2/3] nvme: " Mikulas Patocka
2022-02-01 19:18 ` Bart Van Assche
2022-02-01 19:25 ` Mikulas Patocka
2022-02-01 18:33 ` [RFC PATCH 3/3] nvme: add the "debug" host driver Mikulas Patocka
2022-02-02 6:01 ` Adam Manzanares
2022-02-03 16:06 ` Luis Chamberlain
2022-02-03 16:15 ` Christoph Hellwig
2022-02-03 19:34 ` Luis Chamberlain
2022-02-03 19:46 ` Adam Manzanares
2022-02-03 20:57 ` Mikulas Patocka
2022-02-03 22:52 ` Adam Manzanares
2022-02-04 3:00 ` Chaitanya Kulkarni
2022-02-04 3:05 ` Chaitanya Kulkarni
2022-02-02 8:00 ` Chaitanya Kulkarni
2022-02-02 12:38 ` Klaus Jensen
2022-02-03 15:38 ` Luis Chamberlain
2022-02-03 16:52 ` Keith Busch
2022-02-03 19:50 ` Adam Manzanares
2022-02-04 3:12 ` Chaitanya Kulkarni
2022-02-04 6:28 ` Damien Le Moal
2022-02-04 7:58 ` Chaitanya Kulkarni
2022-02-04 8:24 ` Javier González
2022-02-04 9:58 ` Chaitanya Kulkarni
2022-02-04 11:34 ` Javier González [this message]
2022-02-04 14:15 ` Hannes Reinecke
2022-02-04 14:24 ` Keith Busch
2022-02-04 16:01 ` Christoph Hellwig
2022-02-04 19:41 ` [RFC PATCH 0/3] NVMe copy offload patches Nitesh Shetty
[not found] ` <CGME20220207141901epcas5p162ec2387815be7a1fd67ce0ab7082119@epcas5p1.samsung.com>
2022-02-07 14:13 ` [PATCH v2 00/10] Add Copy offload support Nitesh Shetty
[not found] ` <CGME20220207141908epcas5p4f270c89fc32434ea8b525fa973098231@epcas5p4.samsung.com>
2022-02-07 14:13 ` [PATCH v2 01/10] block: make bio_map_kern() non static Nitesh Shetty
[not found] ` <CGME20220207141913epcas5p4d41cb549b7cca1ede5c7a66bbd110da0@epcas5p4.samsung.com>
2022-02-07 14:13 ` [PATCH v2 02/10] block: Introduce queue limits for copy-offload support Nitesh Shetty
2022-02-08 7:01 ` Damien Le Moal
2022-02-08 18:43 ` Nitesh Shetty
[not found] ` <CGME20220207141918epcas5p4f9badc0c3f3f0913f091c850d2d3bd81@epcas5p4.samsung.com>
2022-02-07 14:13 ` [PATCH v2 03/10] block: Add copy offload support infrastructure Nitesh Shetty
2022-02-07 22:45 ` kernel test robot
2022-02-07 23:26 ` kernel test robot
2022-02-08 7:21 ` Damien Le Moal
2022-02-09 10:22 ` Nitesh Shetty
2022-02-09 7:48 ` Dan Carpenter
2022-02-09 10:32 ` Nitesh Shetty
[not found] ` <CGME20220207141924epcas5p26ad9cf5de732224f408aded12ed0a577@epcas5p2.samsung.com>
2022-02-07 14:13 ` [PATCH v2 04/10] block: Introduce a new ioctl for copy Nitesh Shetty
2022-02-09 3:39 ` kernel test robot
[not found] ` <CGME20220207141930epcas5p2bcbff65f78ad1dede64648d73ddb3770@epcas5p2.samsung.com>
2022-02-07 14:13 ` [PATCH v2 05/10] block: add emulation " Nitesh Shetty
2022-02-08 3:20 ` kernel test robot
2022-02-16 13:32 ` Mikulas Patocka
2022-02-17 13:18 ` Nitesh Shetty
[not found] ` <CGME20220207141937epcas5p2bd57ae35056c69b3e2f9ee2348d6af19@epcas5p2.samsung.com>
2022-02-07 14:13 ` [PATCH v2 06/10] nvme: add copy support Nitesh Shetty
2022-02-10 7:08 ` kernel test robot
[not found] ` <CGME20220207141942epcas5p4bda894a5833513c9211dcecc7928a951@epcas5p4.samsung.com>
2022-02-07 14:13 ` [PATCH v2 07/10] nvmet: add copy command support for bdev and file ns Nitesh Shetty
2022-02-07 18:10 ` kernel test robot
2022-02-07 20:12 ` kernel test robot
2022-02-10 8:31 ` kernel test robot
2022-02-11 7:52 ` Dan Carpenter
[not found] ` <CGME20220207141948epcas5p4534f6bdc5a1e2e676d7d09c04f8b4a5b@epcas5p4.samsung.com>
2022-02-07 14:13 ` [PATCH v2 08/10] dm: Add support for copy offload Nitesh Shetty
2022-02-16 13:51 ` Mikulas Patocka
2022-02-24 12:42 ` Nitesh Shetty
2022-02-25 9:12 ` Mikulas Patocka
[not found] ` <CGME20220207141953epcas5p32ccc3c0bbe642cea074edefcc32302a5@epcas5p3.samsung.com>
2022-02-07 14:13 ` [PATCH v2 09/10] dm: Enable copy offload for dm-linear target Nitesh Shetty
[not found] ` <CGME20220207141958epcas5p25f1cd06726217696d13c2dfbea010565@epcas5p2.samsung.com>
2022-02-07 14:13 ` [PATCH v2 10/10] dm kcopyd: use copy offload support Nitesh Shetty
2022-02-07 9:57 ` [LSF/MM/BFP ATTEND] [LSF/MM/BFP TOPIC] Storage: Copy Offload Nitesh Shetty
2022-02-02 5:57 ` Kanchan Joshi
2022-02-07 10:45 ` David Disseldorp
2022-03-01 17:34 ` Nikos Tsironis
2022-03-01 21:32 ` Chaitanya Kulkarni
2022-03-03 18:36 ` Nikos Tsironis
2022-03-08 20:48 ` Nikos Tsironis
2022-03-09 8:51 ` Mikulas Patocka
2022-03-09 15:49 ` Nikos Tsironis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220204113423.jmynvz4w5u6wdban@ArmHalley.local \
--to=javier@javigon.com \
--cc=Frederick.Knight@netapp.com \
--cc=a.manzanares@samsung.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=clm@fb.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=djwong@kernel.org \
--cc=dm-devel@redhat.com \
--cc=dsterba@suse.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jack@suse.com \
--cc=josef@toxicpanda.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=mpatocka@redhat.com \
--cc=msnitzer@redhat.com \
--cc=osandov@fb.com \
--cc=roland@purestorage.com \
--cc=tytso@mit.edu \
--cc=zach.brown@ni.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).