[ofw] change layout of ib_send_wr for winof 2.0

Sean Hefty sean.hefty at intel.com
Tue May 27 08:46:11 PDT 2008


It doesn't work for apps that are using atomics.  The following code snippet
from dapl_ibal_dto.h shows the change:

	wr.remote_ops.vaddr = remote_iov->virtual_address;
	wr.remote_ops.rkey = htonl(remote_iov->rmr_context);
	wr.remote_ops.atomic1 = compare_add;
	wr.remote_ops.atomic2 = swap;
to
	wr.atomic_ops.vaddr = remote_iov->virtual_address;
	wr.atomic_ops.rkey = htonl(remote_iov->rmr_context);
	wr.atomic_ops.atomic1 = compare_add;
	wr.atomic_ops.atomic2 = swap;

No other in-tree ULP is affected.  We could probably get fancy with #define's or
change the windows layout of an OFED ibv_send_wr to match with IBAL ib_send_wr,
but the OFED layout avoids internal structure padding and creates a shorter
structure (by using a union).  So, the layout change is an improvement
independent of supporting the OFED interfaces.

I have the changes in my private tree, and they were fairly straightforward to
make.  Although when I create a patch for this, I'll see if I can come up with
something slightly different that doesn't require any ULP code changes.

- Sean


>Could you bring an example, when it doesn't work ?
>
>> -----Original Message-----
>> From: ofw-bounces at lists.openfabrics.org
>> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Sean Hefty
>> Sent: Saturday, May 24, 2008 12:38 AM
>> To: Hefty, Sean; ofw at lists.openfabrics.org
>> Subject: RE: [ofw] change layout of ib_send_wr for winof 2.0
>>
>> Unless we separate the atomic operations into a new named
>> structure, a simple cast doesn't always work.  So at least
>> any code using atomics would need a slight modification.  If
>> I change ib_send_wr in my tree to:
>>
>> typedef struct _ib_send_wr
>> {
>> 	uint64_t					wr_id;
>> 	struct _ib_send_wr*			p_next;
>> 	ib_local_ds_t*				ds_array;
>> 	uint32_t					num_ds;
>> 	ib_send_opt_t				send_opt;
>> 	ib_wr_type_t				wr_type;
>> 	ib_net32_t					immediate_data;
>>
>> 	union
>> 	{
>> 		union _send_dgrm
>> 		{
>> 			struct _send_ud
>> 			{
>> 				ib_av_handle_t h_av;
>> 				ib_net32_t		remote_qp;
>> 				ib_net32_t		remote_qkey;
>> 				void*			rsvd;
>> 				uint16_t		pkey_index;
>>
>> 			}	ud;
>>
>> 			struct _send_rd
>> 			{
>> 				ib_net32_t		remote_qp;
>> 				ib_net32_t		remote_qkey;
>> 				ib_net32_t		eecn;
>>
>> 			}	rd;
>>
>> 			struct _send_raw_ether
>> 			{
>> 				ib_net16_t		dest_lid;
>> 				uint8_t			path_bits;
>> 				uint8_t			sl;
>> 				uint8_t			max_static_rate;
>> 				ib_net16_t		ether_type;
>>
>> 			}	raw_ether;
>>
>> 			struct _send_raw_ipv6
>> 			{
>> 				ib_net16_t		dest_lid;
>> 				uint8_t			path_bits;
>> 				uint8_t			sl;
>> 				uint8_t			max_static_rate;
>>
>> 			}	raw_ipv6;
>>
>> 		}	dgrm;
>>
>> 		struct _send_remote_ops
>> 		{
>> 			uint64_t			vaddr;
>> 			net32_t				rkey;
>>
>> 		}	remote_ops;
>>
>> 		struct _send_atomic_ops
>> 		{
>> 			uint64_t			vaddr;
>> 			ib_net64_t			atomic1;
>> 			ib_net64_t			atomic2;
>> 			net32_t				rkey;
>>
>> 		}	atomic_ops;
>> 	};
>> }	ib_send_wr_t;
>>
>> Then only a uDAPL header file, plus the HW drivers/libraries
>> need updating.
>>
>> - Sean
>>
>> _______________________________________________
>> ofw mailing list
>> ofw at lists.openfabrics.org
>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>>




More information about the ofw mailing list