Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 11/3/2013 4:41 PM, Bart Van Assche wrote:
On 3/11/2013 4:15, Sagi Grimberg wrote:
On 11/1/2013 8:46 PM, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * Signature T10-DIF block-guard types
+ */
+enum ib_t10_dif_bg_type {
+IB_T10DIF_CRC,
+IB_T10DIF_CSUM
+};
In SPC-4 paragraph 4.22.4 I found that the T10-PI guard is the CRC
computed from the generator polynomial x^16 + x^15 + x^11 + x^9 + x^8
+ x^7 + x^5 + x^4 + x^2 + x + 1. Could you tell me where I can find
which guard computation method IB_T10DIF_CSUM corresponds to ?
Bart.
The IB_T10DIF_CSUM computation method corresponds to IP checksum rules.
this is aligned with SHOST_DIX_GUARD_IP guard type.
Since the declarations added in constitute an
interface definition I think it would help if it would be made more
clear what these two symbols stand for. How about mentioning the names
of the standards these two guard computation methods come from ? An
alternative is to add a comment like the one above
scsi_host_guard_type in which explains the two
guard computation methods well:
/*
* All DIX-capable initiators must support the T10-mandated CRC
* checksum. Controllers can optionally implement the IP checksum
* scheme which has much lower impact on system performance. Note
* that the main rationale for the checksum is to match integrity
* metadata with data. Detecting bit errors are a job for ECC memory
* and buses.
*/
Bart.
Agreed,
I'll comment on each type correspondence (T10-DIF CRC checksum and IP
checksum).
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 3/11/2013 4:15, Sagi Grimberg wrote:
On 11/1/2013 8:46 PM, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * Signature T10-DIF block-guard types
+ */
+enum ib_t10_dif_bg_type {
+IB_T10DIF_CRC,
+IB_T10DIF_CSUM
+};
In SPC-4 paragraph 4.22.4 I found that the T10-PI guard is the CRC
computed from the generator polynomial x^16 + x^15 + x^11 + x^9 + x^8
+ x^7 + x^5 + x^4 + x^2 + x + 1. Could you tell me where I can find
which guard computation method IB_T10DIF_CSUM corresponds to ?
Bart.
The IB_T10DIF_CSUM computation method corresponds to IP checksum rules.
this is aligned with SHOST_DIX_GUARD_IP guard type.
Since the declarations added in constitute an
interface definition I think it would help if it would be made more
clear what these two symbols stand for. How about mentioning the names
of the standards these two guard computation methods come from ? An
alternative is to add a comment like the one above scsi_host_guard_type
in which explains the two guard computation methods well:
/*
* All DIX-capable initiators must support the T10-mandated CRC
* checksum. Controllers can optionally implement the IP checksum
* scheme which has much lower impact on system performance. Note
* that the main rationale for the checksum is to match integrity
* metadata with data. Detecting bit errors are a job for ECC memory
* and buses.
*/
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 11/1/2013 8:46 PM, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * Signature T10-DIF block-guard types
+ */
+enum ib_t10_dif_bg_type {
+IB_T10DIF_CRC,
+IB_T10DIF_CSUM
+};
In SPC-4 paragraph 4.22.4 I found that the T10-PI guard is the CRC
computed from the generator polynomial x^16 + x^15 + x^11 + x^9 + x^8
+ x^7 + x^5 + x^4 + x^2 + x + 1. Could you tell me where I can find
which guard computation method IB_T10DIF_CSUM corresponds to ?
Bart.
The IB_T10DIF_CSUM computation method corresponds to IP checksum rules.
this is aligned with SHOST_DIX_GUARD_IP guard type.
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 11/2/2013 12:23 AM, Bart Van Assche wrote: On 31/10/2013 5:24, Sagi Grimberg wrote: + * @type3_inc_reftag: T10-DIF type 3 does not state + *about the reference tag, it is the user + *choice to increment it or not. Can you explain this further ? Does this mean that the HCA can check whether the reference tags are increasing when receiving data for TYPE 3 protection mode ? My understanding of SPC-4 is that the application is free to use the reference tag in any way when using TYPE 3 protection and hence that the HCA must not check whether the reference tag is increasing for TYPE 3 protection. See e.g. sd_dif_type3_get_tag() in drivers/scsi/sd_dif.c. Bart. As I understand TYPE 3, the reference tag is free for the application to use - which may choose to inc it each PI or not. This option allows the application to inc ref_tag in type 3. The DIF check is determined via check_mask. As I see it, correct use in case of DIF TYPE 3 is not to validate reference tag i.e. set REF_TAG bits in check_mask to zero. Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 11/1/2013 5:13 PM, Bart Van Assche wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * struct ib_sig_domain - Parameters specific for T10-DIF
+ * domain.
+ * @sig_type: specific signauture type
+ * @sig: union of all signature domain attributes that may
+ * be used to set domain layout.
+ * @dif:
+ * @type: T10-DIF type (0|1|2|3)
+ * @bg_type: T10-DIF block guard type (CRC|CSUM)
+ * @block_size: block size in signature domain.
+ * @app_tag: if app_tag is owned be the user,
+ * HCA will take this value to be app_tag.
+ * @ref_tag: initial ref_tag of signature handover.
+ * @type3_inc_reftag: T10-DIF type 3 does not state
+ *about the reference tag, it is the user
+ *choice to increment it or not.
+ */
+struct ib_sig_domain {
+enum ib_signature_type sig_type;
+union {
+struct {
+enum ib_t10_dif_typetype;
+enum ib_t10_dif_bg_type bg_type;
+u16block_size;
+u16bg;
+u16app_tag;
+u32ref_tag;
+booltype3_inc_reftag;
+} dif;
+} sig;
+};
My understanding from SPC-4 is that in that when using protection
information such information is inserted after every protection
interval. A protection interval can be smaller than a logical block.
Shouldn't the name "block_size" be changed into something like
"pi_interval" to avoid confusion with the logical block size ?
Bart.
True, for DIF types 2,3 protection interval is not restricted to be
logical block length and may be smaller.
I agree with pi_interval naming.
Note that pi_intervals smaller than 512 bytes are not supported at the
moment.
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 31/10/2013 5:24, Sagi Grimberg wrote: + * @type3_inc_reftag: T10-DIF type 3 does not state + * about the reference tag, it is the user + * choice to increment it or not. Can you explain this further ? Does this mean that the HCA can check whether the reference tags are increasing when receiving data for TYPE 3 protection mode ? My understanding of SPC-4 is that the application is free to use the reference tag in any way when using TYPE 3 protection and hence that the HCA must not check whether the reference tag is increasing for TYPE 3 protection. See e.g. sd_dif_type3_get_tag() in drivers/scsi/sd_dif.c. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * Signature T10-DIF block-guard types
+ */
+enum ib_t10_dif_bg_type {
+ IB_T10DIF_CRC,
+ IB_T10DIF_CSUM
+};
In SPC-4 paragraph 4.22.4 I found that the T10-PI guard is the CRC
computed from the generator polynomial x^16 + x^15 + x^11 + x^9 + x^8 +
x^7 + x^5 + x^4 + x^2 + x + 1. Could you tell me where I can find which
guard computation method IB_T10DIF_CSUM corresponds to ?
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 02/10] IB/core: Introduce Signature Verbs API
On 31/10/2013 5:24, Sagi Grimberg wrote:
+/**
+ * struct ib_sig_domain - Parameters specific for T10-DIF
+ * domain.
+ * @sig_type: specific signauture type
+ * @sig: union of all signature domain attributes that may
+ * be used to set domain layout.
+ * @dif:
+ * @type: T10-DIF type (0|1|2|3)
+ * @bg_type: T10-DIF block guard type (CRC|CSUM)
+ * @block_size: block size in signature domain.
+ * @app_tag: if app_tag is owned be the user,
+ * HCA will take this value to be app_tag.
+ * @ref_tag: initial ref_tag of signature handover.
+ * @type3_inc_reftag: T10-DIF type 3 does not state
+ * about the reference tag, it is the user
+ * choice to increment it or not.
+ */
+struct ib_sig_domain {
+ enum ib_signature_type sig_type;
+ union {
+ struct {
+ enum ib_t10_dif_typetype;
+ enum ib_t10_dif_bg_type bg_type;
+ u16 block_size;
+ u16 bg;
+ u16 app_tag;
+ u32 ref_tag;
+ booltype3_inc_reftag;
+ } dif;
+ } sig;
+};
My understanding from SPC-4 is that in that when using protection
information such information is inserted after every protection
interval. A protection interval can be smaller than a logical block.
Shouldn't the name "block_size" be changed into something like
"pi_interval" to avoid confusion with the logical block size ?
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
