[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