[LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[sagi grimberg]

Hey SCSI folks,

I'd like to propose the following topic for upcoming LSF-MM:

T10-PI standard is becoming more and more appealing for storage and 
cloud solutions. Since error-detection
coding comes with its cost of CPU computation overhead, state-of-the-art 
ASICs offer the ability to offload
T10-PI operations (DIF/DIX), examples are SAS & FC controllers. 
Recently, the support for T10-PI offload over
RDMA transactions was introduced in the Mellanox Connect-IB HCA.

The first building block, RDMA verbs API supporting T10-PI offload was 
submitted over Linux-rdma (see
http://marc.info/?l=linux-rdma&m=138719320307936&w=2). Moreover, We have 
seen first seeds of T10-PI
support in Linux SCSI target entering v3.14 (see 
http://lwn.net/Articles/579708/) and RDMA offload
implementation in iSER transport (see 
http://www.spinics.net/lists/linux-scsi/msg71128.html). There is
still some ground to fill to get protection information support to a 
full solution over all backend devices.

We would like to use LSF-MM platform to to push forward T10-PI support 
end-to-end which requires Linux SCSI
Target core level support along with transport level support in iSER and 
SRP (and also FCoE in the future) and
over to the Initiator side transports.

Discussion topics:
- Introduce T10-PI offload RDMA verbs and how are used in storage 
applications.
- Discuss effects of DIX1.1 (currently a draft) in Target implementation 
(core level -> transport level -> HW level).
- Discuss T10-PI Type 4 (16-byte DIF) status and possible implications 
on Target & Initiator implementation down to HW level.
- Discuss Current Limitations that T10-PI RDMA offload poses on iSCSI 
protocol (ImmediateData, UnsolDataOut) and if/how they can be solved.
- What-ever else comes to mind...

Thanks,
Sagi.

Re: [LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[James Bottomley]

On Thu, 2014-01-16 at 14:26 +0200, sagi grimberg wrote:

>                From:
> sagi grimberg <sagig@mellanox.com>
>                 To:
> linux-scsi
> <linux-scsi@vger.kernel.org>,
> target-devel
> <target-devel@vger.kernel.org>
>                 Cc:
> Oren Duer <oren@mellanox.com>

Actually, could you copy lsf-pc@lists.linux-foundation.org like the CFP
requests?  The reason is quite simple: the people tracking the topic and
attend requests use that list and don't scan any others.

Thanks,

James

[LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[Sagi Grimberg]

Hey SCSI (and LSF) folks,

I'd like to propose the following topic for upcoming LSF-MM:

T10-PI standard is becoming more and more appealing for storage and 
cloud solutions.
Since error-detection coding comes with its cost of CPU computation 
overhead,
state-of-the-art ASICs offer the ability to offload T10-PI operations 
(DIF/DIX), examples
are SAS & FC controllers. Recently, the support for T10-PI offload over 
RDMA transactions
was introduced in the Mellanox Connect-IB HCA.

The first building block, RDMA verbs API supporting T10-PI offload was 
submitted over
Linux-rdma (see http://marc.info/?l=linux-rdma&m=138719320307936&w=2). 
Moreover,
we have seen first seeds of T10-PI support in Linux SCSI target entering 
v3.14 (see
http://lwn.net/Articles/579708/) and RDMA offload implementation in iSER 
transport
(see http://www.spinics.net/lists/linux-scsi/msg71128.html). There is 
still some ground to
fill to get protection information support to a full solution over all 
backend devices.

We would like to use LSF-MM platform to to push forward T10-PI support 
end-to-end which
requires Linux SCSI Target core level support along with transport level 
support in iSER and SRP
(and also FCoE in the future) and over to the Initiator side transports.

Discussion topics:
- Introduce T10-PI offload RDMA verbs and how are used in storage 
applications.
- Discuss effects of DIX1.1 (currently a draft) in Target implementation 
(core level -> transport level -> HW level).
- Discuss T10-PI Type 4 (16-byte DIF) status and possible implications 
on Target & Initiator implementation down to HW level.
- Discuss Current Limitations that T10-PI RDMA offload poses on iSCSI 
protocol (ImmediateData, UnsolDataOut) and if/how
   they can be solved.
- What-ever else comes to mind...

Thanks,
Sagi.

Re: [LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[Nicholas A. Bellinger]

On Thu, 2014-01-16 at 17:12 +0200, Sagi Grimberg wrote:
> Hey SCSI (and LSF) folks,
> 
> I'd like to propose the following topic for upcoming LSF-MM:
> 
> T10-PI standard is becoming more and more appealing for storage and 
> cloud solutions.
> Since error-detection coding comes with its cost of CPU computation 
> overhead,
> state-of-the-art ASICs offer the ability to offload T10-PI operations 
> (DIF/DIX), examples
> are SAS & FC controllers. Recently, the support for T10-PI offload over 
> RDMA transactions
> was introduced in the Mellanox Connect-IB HCA.
> 
> The first building block, RDMA verbs API supporting T10-PI offload was 
> submitted over
> Linux-rdma (see http://marc.info/?l=linux-rdma&m=138719320307936&w=2). 
> Moreover,
> we have seen first seeds of T10-PI support in Linux SCSI target entering 
> v3.14 (see
> http://lwn.net/Articles/579708/) and RDMA offload implementation in iSER 
> transport
> (see http://www.spinics.net/lists/linux-scsi/msg71128.html). There is 
> still some ground to
> fill to get protection information support to a full solution over all 
> backend devices.
> 
> We would like to use LSF-MM platform to to push forward T10-PI support 
> end-to-end which
> requires Linux SCSI Target core level support along with transport level 
> support in iSER and SRP
> (and also FCoE in the future) and over to the Initiator side transports.
> 
> Discussion topics:
> - Introduce T10-PI offload RDMA verbs and how are used in storage 
> applications.
> - Discuss effects of DIX1.1 (currently a draft) in Target implementation 
> (core level -> transport level -> HW level).
> - Discuss T10-PI Type 4 (16-byte DIF) status and possible implications 
> on Target & Initiator implementation down to HW level.
> - Discuss Current Limitations that T10-PI RDMA offload poses on iSCSI 
> protocol (ImmediateData, UnsolDataOut) and if/how
>    they can be solved.
> - What-ever else comes to mind...

+1  (CC'ing Roland + MKP)

Looking forward to seeing protection information enabled within iser
initiator code, and perhaps even an optional software emulation for
traditional iscsi fabric code.

--nab

Re: [LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[Quinn Tran]

On 1/16/14 7:12 AM, "Sagi Grimberg" <sagig@dev.mellanox.co.il> wrote:

>Hey SCSI (and LSF) folks,
>
>I'd like to propose the following topic for upcoming LSF-MM:
>
>T10-PI standard is becoming more and more appealing for storage and
>cloud solutions.
>Since error-detection coding comes with its cost of CPU computation
>overhead,
>state-of-the-art ASICs offer the ability to offload T10-PI operations
>(DIF/DIX), examples
>are SAS & FC controllers. Recently, the support for T10-PI offload over
>RDMA transactions
>was introduced in the Mellanox Connect-IB HCA.
>
>The first building block, RDMA verbs API supporting T10-PI offload was
>submitted over
>Linux-rdma (see http://marc.info/?l=linux-rdma&m=138719320307936&w=2).
>Moreover,
>we have seen first seeds of T10-PI support in Linux SCSI target entering
>v3.14 (see
>http://lwn.net/Articles/579708/) and RDMA offload implementation in iSER
>transport
>(see http://www.spinics.net/lists/linux-scsi/msg71128.html). There is
>still some ground to
>fill to get protection information support to a full solution over all
>backend devices.
>
>We would like to use LSF-MM platform to to push forward T10-PI support
>end-to-end which
>requires Linux SCSI Target core level support along with transport level
>support in iSER and SRP
>(and also FCoE in the future) and over to the Initiator side transports.
>
>Discussion topics:
>- Introduce T10-PI offload RDMA verbs and how are used in storage
>applications.
>- Discuss effects of DIX1.1 (currently a draft) in Target implementation
>(core level -> transport level -> HW level).
>- Discuss T10-PI Type 4 (16-byte DIF) status and possible implications
>on Target & Initiator implementation down to HW level.
>- Discuss Current Limitations that T10-PI RDMA offload poses on iSCSI
>protocol (ImmediateData, UnsolDataOut) and if/how
>   they can be solved.
>- What-ever else comes to mind...

+1

Would like to hear this discussion and see how this implementation can
expand to Fibre Channel HW offload(Target mode storage).

Regards,
Quinn Tran




>
>Thanks,
>Sagi.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


________________________________

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

Re: [LSF/MM TOPIC][ATTEND] T10-PI RDMA offload

[Bart Van Assche]

On 01/16/14 16:12, Sagi Grimberg wrote:
> Hey SCSI (and LSF) folks,
> 
> I'd like to propose the following topic for upcoming LSF-MM:
> 
> T10-PI standard is becoming more and more appealing for storage and
> cloud solutions.
> Since error-detection coding comes with its cost of CPU computation
> overhead,
> state-of-the-art ASICs offer the ability to offload T10-PI operations
> (DIF/DIX), examples
> are SAS & FC controllers. Recently, the support for T10-PI offload over
> RDMA transactions
> was introduced in the Mellanox Connect-IB HCA.
> 
> The first building block, RDMA verbs API supporting T10-PI offload was
> submitted over
> Linux-rdma (see http://marc.info/?l=linux-rdma&m=138719320307936&w=2).
> Moreover,
> we have seen first seeds of T10-PI support in Linux SCSI target entering
> v3.14 (see
> http://lwn.net/Articles/579708/) and RDMA offload implementation in iSER
> transport
> (see http://www.spinics.net/lists/linux-scsi/msg71128.html). There is
> still some ground to
> fill to get protection information support to a full solution over all
> backend devices.
> 
> We would like to use LSF-MM platform to to push forward T10-PI support
> end-to-end which
> requires Linux SCSI Target core level support along with transport level
> support in iSER and SRP
> (and also FCoE in the future) and over to the Initiator side transports.
> 
> Discussion topics:
> - Introduce T10-PI offload RDMA verbs and how are used in storage
> applications.
> - Discuss effects of DIX1.1 (currently a draft) in Target implementation
> (core level -> transport level -> HW level).
> - Discuss T10-PI Type 4 (16-byte DIF) status and possible implications
> on Target & Initiator implementation down to HW level.
> - Discuss Current Limitations that T10-PI RDMA offload poses on iSCSI
> protocol (ImmediateData, UnsolDataOut) and if/how
>   they can be solved.
> - What-ever else comes to mind...

+1 for this topic.

As a contributor to the SRP protocol implementation I'm interested in
this discussion. Having an API for T10-PI offload in the RDMA core is a
prerequisite before T10-PI support can be added in the SRP initiator and
target drivers.

Bart.