All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: "Javier González" <javier@javigon.com>
Cc: Hannes Reinecke <hare@suse.de>, Christoph Hellwig <hch@lst.de>,
	SelvaKumar S <selvakuma.s1@samsung.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"kbusch@kernel.org" <kbusch@kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"snitzer@redhat.com" <snitzer@redhat.com>,
	"selvajove@gmail.com" <selvajove@gmail.com>,
	"nj.shetty@samsung.com" <nj.shetty@samsung.com>,
	"joshi.k@samsung.com" <joshi.k@samsung.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [RFC PATCH v2 0/2] add simple copy support
Date: Tue, 8 Dec 2020 13:24:40 +0000	[thread overview]
Message-ID: <SN4PR0401MB3598226CD4A32F65320A47379BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20201208131333.xoxincxcnh7iz33z@mpHalley

On 08/12/2020 14:13, Javier González wrote:
> On 08.12.2020 12:37, Johannes Thumshirn wrote:
>> On 08/12/2020 13:22, Javier González wrote:
>>> Good idea. Are you thinking of a sysfs entry to select the backend?
>>
>> Not sure on this one, initially I thought of a sysfs file, but then
>> how would you do it. One "global" sysfs entry is probably a bad idea.
>> Having one per block device to select native vs emulation maybe? And
>> a good way to benchmark.
> 
> I was thinking a per block device to target the use case where a certain
> implementation / workload is better one way or the other.

Yes something along those lines.

>>
>> The other idea would be a benchmark loop on boot like the raid library
>> does.
>>
>> Then on the other hand, there might be workloads that run faster with
>> the emulation and some that run faster with the hardware acceleration.
>>
>> I think these points are the reason the last attempts got stuck.
> 
> Yes. I believe that any benchmark we run would be biased in a certain
> way. If we can move forward with a sysfs entry and default to legacy
> path, we would not alter current behavior and enable NVMe copy offload
> (for now) for those that want to use it. We can then build on top of it.
> 
> Does this sound like a reasonable approach?
> 

Yes this sounds like a reasonable approach to me.

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: "Javier González" <javier@javigon.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	SelvaKumar S <selvakuma.s1@samsung.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"snitzer@redhat.com" <snitzer@redhat.com>,
	"selvajove@gmail.com" <selvajove@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"nj.shetty@samsung.com" <nj.shetty@samsung.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	"joshi.k@samsung.com" <joshi.k@samsung.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"kbusch@kernel.org" <kbusch@kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [RFC PATCH v2 0/2] add simple copy support
Date: Tue, 8 Dec 2020 13:24:40 +0000	[thread overview]
Message-ID: <SN4PR0401MB3598226CD4A32F65320A47379BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20201208131333.xoxincxcnh7iz33z@mpHalley

On 08/12/2020 14:13, Javier González wrote:
> On 08.12.2020 12:37, Johannes Thumshirn wrote:
>> On 08/12/2020 13:22, Javier González wrote:
>>> Good idea. Are you thinking of a sysfs entry to select the backend?
>>
>> Not sure on this one, initially I thought of a sysfs file, but then
>> how would you do it. One "global" sysfs entry is probably a bad idea.
>> Having one per block device to select native vs emulation maybe? And
>> a good way to benchmark.
> 
> I was thinking a per block device to target the use case where a certain
> implementation / workload is better one way or the other.

Yes something along those lines.

>>
>> The other idea would be a benchmark loop on boot like the raid library
>> does.
>>
>> Then on the other hand, there might be workloads that run faster with
>> the emulation and some that run faster with the hardware acceleration.
>>
>> I think these points are the reason the last attempts got stuck.
> 
> Yes. I believe that any benchmark we run would be biased in a certain
> way. If we can move forward with a sysfs entry and default to legacy
> path, we would not alter current behavior and enable NVMe copy offload
> (for now) for those that want to use it. We can then build on top of it.
> 
> Does this sound like a reasonable approach?
> 

Yes this sounds like a reasonable approach to me.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: "Javier González" <javier@javigon.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	S <selvakuma.s1@samsung.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>,
	"snitzer@redhat.com" <snitzer@redhat.com>,
	SelvaKumar, "selvajove@gmail.com" <selvajove@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"nj.shetty@samsung.com" <nj.shetty@samsung.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	Patocka <mpatocka@redhat.com>,
	"joshi.k@samsung.com" <joshi.k@samsung.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"kbusch@kernel.org" <kbusch@kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Mikulas, Bart Van Assche <bvanassche@acm.org>
Subject: Re: [dm-devel] [RFC PATCH v2 0/2] add simple copy support
Date: Tue, 8 Dec 2020 13:24:40 +0000	[thread overview]
Message-ID: <SN4PR0401MB3598226CD4A32F65320A47379BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20201208131333.xoxincxcnh7iz33z@mpHalley

On 08/12/2020 14:13, Javier González wrote:
> On 08.12.2020 12:37, Johannes Thumshirn wrote:
>> On 08/12/2020 13:22, Javier González wrote:
>>> Good idea. Are you thinking of a sysfs entry to select the backend?
>>
>> Not sure on this one, initially I thought of a sysfs file, but then
>> how would you do it. One "global" sysfs entry is probably a bad idea.
>> Having one per block device to select native vs emulation maybe? And
>> a good way to benchmark.
> 
> I was thinking a per block device to target the use case where a certain
> implementation / workload is better one way or the other.

Yes something along those lines.

>>
>> The other idea would be a benchmark loop on boot like the raid library
>> does.
>>
>> Then on the other hand, there might be workloads that run faster with
>> the emulation and some that run faster with the hardware acceleration.
>>
>> I think these points are the reason the last attempts got stuck.
> 
> Yes. I believe that any benchmark we run would be biased in a certain
> way. If we can move forward with a sysfs entry and default to legacy
> path, we would not alter current behavior and enable NVMe copy offload
> (for now) for those that want to use it. We can then build on top of it.
> 
> Does this sound like a reasonable approach?
> 

Yes this sounds like a reasonable approach to me.



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2020-12-08 13:25 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20201204094719epcas5p23b3c41223897de3840f92ae3c229cda5@epcas5p2.samsung.com>
2020-12-04  9:46 ` [RFC PATCH v2 0/2] add simple copy support SelvaKumar S
2020-12-04  9:46   ` [dm-devel] " SelvaKumar S
2020-12-04  9:46   ` SelvaKumar S
     [not found]   ` <CGME20201204094731epcas5p307fe5a0b9360c5057cd48e42c9300053@epcas5p3.samsung.com>
2020-12-04  9:46     ` [RFC PATCH v2 1/2] block: " SelvaKumar S
2020-12-04  9:46       ` [dm-devel] " SelvaKumar S
2020-12-04  9:46       ` SelvaKumar S
2020-12-09  4:19       ` [dm-devel] " Martin K. Petersen
2020-12-09  4:19         ` Martin K. Petersen
2020-12-09  4:19         ` Martin K. Petersen
2020-12-09  5:17         ` Damien Le Moal
2020-12-09  5:17           ` Damien Le Moal
2020-12-09  5:17           ` Damien Le Moal
     [not found]   ` <CGME20201204094747epcas5p121b6eccf78a29ed4cba7c22d6b42d160@epcas5p1.samsung.com>
2020-12-04  9:46     ` [RFC PATCH v2 2/2] nvme: " SelvaKumar S
2020-12-04  9:46       ` [dm-devel] " SelvaKumar S
2020-12-04  9:46       ` SelvaKumar S
2020-12-04 11:25   ` [RFC PATCH v2 0/2] " Damien Le Moal
2020-12-04 11:25     ` [dm-devel] " Damien Le Moal
2020-12-04 11:25     ` Damien Le Moal
2020-12-04 14:40     ` Keith Busch
2020-12-04 14:40       ` [dm-devel] " Keith Busch
2020-12-04 14:40       ` Keith Busch
2020-12-07  7:46       ` javier.gonz@samsung.com
2020-12-07  7:46         ` [dm-devel] " javier.gonz@samsung.com
2020-12-07  7:46         ` javier.gonz@samsung.com
2020-12-07  8:06         ` Damien Le Moal
2020-12-07  8:06           ` [dm-devel] " Damien Le Moal
2020-12-07  8:06           ` Damien Le Moal
2020-12-07  8:16           ` javier.gonz@samsung.com
2020-12-07  8:16             ` [dm-devel] " javier.gonz@samsung.com
2020-12-07  8:16             ` javier.gonz@samsung.com
2020-12-07  9:01             ` Damien Le Moal
2020-12-07  9:01               ` [dm-devel] " Damien Le Moal
2020-12-07  9:01               ` Damien Le Moal
2020-12-07 14:11   ` Christoph Hellwig
2020-12-07 14:11     ` [dm-devel] " Christoph Hellwig
2020-12-07 14:11     ` Christoph Hellwig
2020-12-07 14:56     ` Hannes Reinecke
2020-12-07 14:56       ` [dm-devel] " Hannes Reinecke
2020-12-07 14:56       ` Hannes Reinecke
2020-12-07 19:24       ` Javier González
2020-12-07 19:24         ` [dm-devel] " Javier González
2020-12-07 19:24         ` Javier González
2020-12-08  8:40         ` Johannes Thumshirn
2020-12-08  8:40           ` [dm-devel] " Johannes Thumshirn
2020-12-08  8:40           ` Johannes Thumshirn
2020-12-08 12:22           ` Javier González
2020-12-08 12:22             ` [dm-devel] " Javier González
2020-12-08 12:22             ` Javier González
2020-12-08 12:37             ` Johannes Thumshirn
2020-12-08 12:37               ` [dm-devel] " Johannes Thumshirn
2020-12-08 12:37               ` Johannes Thumshirn
2020-12-08 13:13               ` Javier González
2020-12-08 13:13                 ` [dm-devel] " Javier González
2020-12-08 13:13                 ` Javier González
2020-12-08 13:24                 ` Johannes Thumshirn [this message]
2020-12-08 13:24                   ` [dm-devel] " Johannes Thumshirn
2020-12-08 13:24                   ` Johannes Thumshirn
2020-12-09  9:17                   ` Javier González
2020-12-09  9:17                     ` [dm-devel] " Javier González
2020-12-09  9:17                     ` Javier González
2020-12-15 23:45               ` Pavel Machek
2020-12-15 23:45                 ` [dm-devel] " Pavel Machek
2020-12-15 23:45                 ` Pavel Machek
2020-12-07 22:12       ` Douglas Gilbert
2020-12-07 22:12         ` [dm-devel] " Douglas Gilbert
2020-12-07 22:12         ` Douglas Gilbert
2020-12-08  6:44         ` Hannes Reinecke
2020-12-08  6:44           ` [dm-devel] " Hannes Reinecke
2020-12-08  6:44           ` Hannes Reinecke
2020-12-08 12:21           ` Javier González
2020-12-08 12:21             ` [dm-devel] " Javier González
2020-12-08 12:21             ` Javier González
2020-12-09  3:02       ` Martin K. Petersen
2020-12-09  3:02         ` [dm-devel] " Martin K. Petersen
2020-12-09  3:02         ` Martin K. Petersen
2020-12-07 19:14     ` Javier González
2020-12-07 19:14       ` [dm-devel] " Javier González
2020-12-07 19:14       ` Javier González

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=SN4PR0401MB3598226CD4A32F65320A47379BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com \
    --to=johannes.thumshirn@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=javier@javigon.com \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mpatocka@redhat.com \
    --cc=nj.shetty@samsung.com \
    --cc=sagi@grimberg.me \
    --cc=selvajove@gmail.com \
    --cc=selvakuma.s1@samsung.com \
    --cc=snitzer@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.