Cc: Jeff Garzik <jeff@...>, Alan Cox <alan@...>, Mike Christie <michaelc@...>, <linux-scsi@...>, Linux Kernel Mailing List <linux-kernel@...>, James Bottomley <James.Bottomley@...>, <scst-devel@...>, Andrew Morton <akpm@...>, Linus Torvalds <torvalds@...>, FUJITA Tomonori <fujita.tomonori@...>, Julian Satran <Julian_Satran@...>
On Tue, 2008-02-05 at 22:01 +0300, Vladislav Bolkhovitin wrote:
Actually, the iSER protocol wire protocol itself is quite simple,
because it builds on iSCSI and IPS fundamentals, and because traditional
iSCSI's recovery logic for CRC failures (and hence alot of
acknowledgement sequence PDUs that go missing, etc) and the RDMA Capable
Protocol (RCaP).
The logic that iSER collectively disables is known as within-connection
and within-command recovery (negotiated as ErrorRecoveryLevel=1 on the
wire), RFC-5046 requires that the iSCSI layer that iSER is being enabled
to disable CRC32C checksums and any associated timeouts for ERL=1.
Also, have a look at Appendix A. in the iSER spec.
A.1. iWARP Message Format for iSER Hello Message ...............73
A.2. iWARP Message Format for iSER HelloReply Message ..........74
A.3. iWARP Message Format for SCSI Read Command PDU ............75
A.4. iWARP Message Format for SCSI Read Data ...................76
A.5. iWARP Message Format for SCSI Write Command PDU ...........77
A.6. iWARP Message Format for RDMA Read Request ................78
A.7. iWARP Message Format for Solicited SCSI Write Data ........79
A.8. iWARP Message Format for SCSI Response PDU ................80
This is about as 1/2 as many traditional iSCSI PDUs, that iSER
encapulates.
--nab
--
