[ofw] changes to ib_wc committed to svn

[Tzachi Dar]

Some answers bellow, more answers in the next mail (reply to fab).

Thanks
Tzachi 

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org 
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Sean Hefty
> Sent: Wednesday, July 23, 2008 11:51 PM
> To: ofw at lists.openfabrics.org
> Subject: [ofw] changes to ib_wc committed to svn
> 
> I must have missed seeing the patch to review the following 
> change to ib_wc:
> 
> typedef struct _ib_wc
> {
> 	TO_LONG_PTR(struct _ib_wc*, p_next);
> 	uint64_t				wr_id;
> 	ib_wc_type_t			wc_type;
> 
> 	uint32_t				length;
> 	ib_wc_status_t			status;
> -	uint64_t				vendor_specific;
> +	struct {
> +		uint8_t				vendor_specific;
> +		uint8_t				csum_ok;
> +		uint16_t			vendor_specific2;
> +		uint32_t			vendor_specific3;
> +	};
> 
> 
> Why was this done?  This splits vendor_specific from a single 
> 64-bit field into
> 3 non-contiguous fields, and consumes 8 bits for a 1 bit 
> flag.  Why not leave this as a uint64_t, with a vendor 
> defined flag indicating if the check sum was valid?  Or just 
> use the ib_recv_opt_t flags that already exist, if this is 
> truly not a vendor specific value?
> 
First thing, CSUM is not 1 bit, but at least 6 bits. That why we thought
that we should use one byte for that.
The main reason that 1 bit is not enough is that there is ip check sum,
udp checksum and tcp check sum.
They are not passed or failed, but rather 3 choices: 1 - csum was
calculated and is ok. 2- csum was calculated and is bad. 3 csum was not
calculated.
>From what we saw, there was no use to more than the 8 bytes of
vendor_specific so we have splited the field into 4 parts. (each is
aligned).

Thanks
Tzachi


> This structure is visible to userspace applications, so 
> keeping it free of ipoib specific information is ideal.
> 
> - Sean
> 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>