Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, 2017-04-12 at 11:09 -0600, Logan Gunthorpe wrote: > > > Do you handle funky address translation too ? IE. the fact that the PCI > > addresses aren't the same as the CPU physical addresses for a BAR ? > > No, we use the CPU physical address of the BAR. If it's not mapped that > way we

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On 11/04/17 11:22 PM, Benjamin Herrenschmidt wrote: > Another issue of course is that not all systems support P2P > between host bridges :-) (Though almost all switches can enable it). Yes, I'm either going to just let the user enable and test or limit it to switches only to start. However,

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Thu, 2017-03-30 at 16:12 -0600, Logan Gunthorpe wrote: > Hello, > > As discussed at LSF/MM we'd like to present our work to enable > copy offload support in NVMe fabrics RDMA targets. We'd appreciate > some review and feedback from the community on our direction. > This seri

[RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

Hello, As discussed at LSF/MM we'd like to present our work to enable copy offload support in NVMe fabrics RDMA targets. We'd appreciate some review and feedback from the community on our direction. This series is not intended to go upstream at this point. The concept here is to use memory

Re: [PATCH 0/15] copy offload patches

> "Mikulas" == Mikulas Patocka writes: Mikulas> Is there some software iSCSI implementation that supports Mikulas> token-based copy? So that I could try to make support for it. I did write support for token-based copy but it's in a different branch from the xcopy stuff.

Re: [PATCH 0/15] copy offload patches

On Thu, 10 Dec 2015, Martin K. Petersen wrote: > >>>>> "Mikulas" == Mikulas Patocka <mpato...@redhat.com> writes: > > Mikulas, > > Mikulas> This patch series adds copy offload (the XCOPY command) to the > Mikulas> block layer, SCSI su

Re: [PATCH 0/15] copy offload patches

On 15-12-14 08:22 PM, Mikulas Patocka wrote: On Thu, 10 Dec 2015, Martin K. Petersen wrote: "Mikulas" == Mikulas Patocka <mpato...@redhat.com> writes: Mikulas, Mikulas> This patch series adds copy offload (the XCOPY command) to the Mikulas> block layer, SCSI subsys

Re: [dm-devel] [PATCH 0/15] copy offload patches

On Thu, Dec 10, 2015 at 11:06:04PM -0600, Mike Christie wrote: > > 2. Start REQ_OP_READ off at non-zero to try and shake out code that was > not converted. > > There are a several places where we assume reads are zero and writes are > 1 for things like indexing in arrays (like blktrace's

[PATCH 13/15] dm kcopyd: support copy offload

This patch adds copy offload support to dm-kcopyd. If copy offload fails, copying is performed using dm-io, just like before. There is a module parameter "copy_offload" that can be set to enable or disable this feature. It can be used to test performance of copy offload. Signed-off-b

[PATCH 15/15] dm kcopyd: call copy offload with asynchronous callback

Change dm kcopyd so that it calls blkdev_issue_copy with an asynchronous callback. There can be large number of pending kcopyd requests and holding a process context for each of them may put too much load on the workqueue subsystem. This patch changes it so that blkdev_issue_copy returns after it

Re: [PATCH 0/15] copy offload patches

>>>>> "Mikulas" == Mikulas Patocka <mpato...@redhat.com> writes: Mikulas, Mikulas> This patch series adds copy offload (the XCOPY command) to the Mikulas> block layer, SCSI subsystems and device mapper. Now that the VFS stuff appears to stabilize I agree it

[PATCH 0/15] copy offload patches

Hi This patch series adds copy offload (the XCOPY command) to the block layer, SCSI subsystems and device mapper. The principle of operation is this: We create two bios with REQ_COPY flag, one for read and one for write. The bios have no data pages and they both point to the same bio_copy

Re: [dm-devel] [PATCH 0/15] copy offload patches

On 12/10/2015 04:33 PM, Martin K. Petersen wrote: >>>>>> "Mikulas" == Mikulas Patocka <mpato...@redhat.com> writes: > > Mikulas, > > Mikulas> This patch series adds copy offload (the XCOPY command) to the > Mikulas> block layer, SCSI su

[PATCH 16/18] dm kcopyd: support copy offload

This patch adds copy offload support to dm-kcopyd. If copy offload fails, copying is performed using dm-io, just like before. There is a module parameter copy_offload that can be set to enable or disable this feature. It can be used to test performance of copy offload. Signed-off-by: Mikulas

[PATCH 18/18] dm kcopyd: call copy offload with asynchronous callback

Change dm kcopyd so that it calls blkdev_issue_copy with an asynchronous callback. There can be large number of pending kcopyd requests and holding a process context for each of them may put too much load on the workqueue subsystem. This patch changes it so that blkdev_issue_copy returns after it

[PATCH 13/15] dm kcopyd: support copy offload

This patch adds copy offload support to dm-kcopyd. If copy offload fails, copying is performed using dm-io, just like before. There is a module parameter copy_offload that can be set to enable or disable this feature. It can be used to test performance of copy offload. Signed-off-by: Mikulas

[PATCH 15/15] dm kcopyd: call copy offload with asynchronous callback

Change dm kcopyd so that it calls blkdev_issue_copy with an asynchronous callback. There can be large number of pending kcopyd requests and holding a process context for each of them may put too much load on the workqueue subsystem. This patch changes it so that blkdev_issue_copy returns after it

Re: [PATCH 2/6] block: Implement support for copy offload operations

On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote: Many modern SCSI devices support copy offloading operations in which one can copy a block range from one LUN to another without the need for data to be copied sent to the host and back. This is particularly useful for things like

Re: [PATCH 3/6] block: Introduce copy offload library function

. blkdev_issue_copy() will iterate over the blocks in the source range and issue copy offload requests using the granularity preferred by source and target. There is no guarantee that a copy offload operation will be successful even if both devices are offload-capable. Filesystems must be prepared

Re: [PATCH 4/6] block: Copy offload ioctl

On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote: Add an ioctl which can be used to clone a block range within a single block device. This is useful for testing the copy offload code. Signed-off-by: Martin K. Petersen martin.peter...@oracle.com --- block/ioctl.c | 35

Re: [PATCH 6/6] [SCSI] sd: Implement copy offload support

On Wed, 2014-05-28 at 23:52 -0400, Martin K. Petersen wrote: Implement support for hardware copy offload. This initial implementation only supports EXTENDED COPY(LID1). If need be we can add support for LID4 or token copy at a later date. If a device has the 3PC flag set in the standard

Re: [PATCH 6/6] [SCSI] sd: Implement copy offload support

On 14-05-28 11:52 PM, Martin K. Petersen wrote: Implement support for hardware copy offload. This initial implementation only supports EXTENDED COPY(LID1). If need be we can add support for LID4 or token copy at a later date. If a device has the 3PC flag set in the standard INQUIRY response

Re: [PATCH 6/6] [SCSI] sd: Implement copy offload support

Doug == Douglas Gilbert dgilb...@interlog.com writes: Doug, Doug SPC-4 has downgraded the RECEIVE COPY OPERATION PARAMETERS command Doug in favour of the new Third Party Copy (TPC) VPD page [0x8f]. If Doug the latter is present, it should be used. Most real world Doug implementations of

[PATCH 3/6] block: Introduce copy offload library function

copy offload requests using the granularity preferred by source and target. There is no guarantee that a copy offload operation will be successful even if both devices are offload-capable. Filesystems must be prepared to manually copy or punt to userland if the operation fails. Signed-off-by: Martin

[PATCH 6/6] [SCSI] sd: Implement copy offload support

Implement support for hardware copy offload. This initial implementation only supports EXTENDED COPY(LID1). If need be we can add support for LID4 or token copy at a later date. If a device has the 3PC flag set in the standard INQUIRY response we'll issue a RECEIVE COPY OPERATION PARAMETERS

Copy offload

Several people have poked me about the copy offload patches. Aside from being able to fit into Jens' 3.16/core branch there hasn't been any changes, nor any bug reports since LSF/MM. This patch series implements support for copy offload. Storage arrays that implement copy operations can be told

[PATCH 2/6] block: Implement support for copy offload operations

...@oracle.com +Description: + Devices that support copy offloading will set this value + to indicate the maximum buffer size in bytes that can be + copied in one operation. If the copy_max_bytes is 0 the + device does not support copy offload. diff

[PATCH 4/6] block: Copy offload ioctl

Add an ioctl which can be used to clone a block range within a single block device. This is useful for testing the copy offload code. Signed-off-by: Martin K. Petersen martin.peter...@oracle.com --- block/ioctl.c | 35 +++ include/uapi/linux/fs.h | 1

Re: [LSF/MM TOPIC] [ATTEND] new generation copy offload (ODX)

On Fri, 2014-01-17 at 12:20 -0500, Douglas Gilbert wrote: Hannes Reinecke and I would like to attend LSF and present a talk on the new generation copy offload (a.k.a. ODX). Most discussions about copy offload at the storage level are based on T10's 15 year old xcopy(LID1), specifically its

[LSF/MM TOPIC] [ATTEND] new generation copy offload (ODX)

Hannes Reinecke and I would like to attend LSF and present a talk on the new generation copy offload (a.k.a. ODX). Most discussions about copy offload at the storage level are based on T10's 15 year old xcopy(LID1), specifically its disk-disk copy. This year T10 hopes to standardize a new

[PATCH-v2 6/9] target: Add support for EXTENDED_COPY copy offload emulation

From: Nicholas Bellinger n...@daterainc.com This patch adds support for EXTENDED_COPY emulation from SPC-3, that enables full copy offload target support within both a single virtual backend device, and across multiple virtual backend devices. It also functions independent of target fabric

[PATCH 6/9] target: Add support for EXTENDED_COPY copy offload emulation

From: Nicholas Bellinger n...@daterainc.com This patch adds support for EXTENDED_COPY emulation from SPC-3, that enables full copy offload target support within both a single virtual backend device, and across multiple virtual backend devices. It also functions independent of target fabric

<    1   2