[ofw] [PATCH] ND Provider: fix service ID byte ordering

Fab Tillier ftillier at microsoft.com
Fri Feb 11 17:05:03 PST 2011


Hefty, Sean wrote on Fri, 11 Feb 2011 at 16:53:43

>> Clearest is probably:
>> 
>>     strut _rdma_cm_sid
>>     {
>>         uint32_t zero;
>>         uint8_t is_rdma_cm;
>>         uint8_t prot;
>>         net16_t port;
>>     } * p_sid = &p_cm_req->service_id;
>>     
>>     p_sid->port = p_req->dst_port;
>>     p_sid->prot = p_req->prot;
>>     p_sid->is_rdma_cm = 1;
>>     p_sid->zero = 0;
> 
> This isn't bad, but I think the port field needs to be in host order, with the
> structure swapped after assignment.  Otherwise, I think the layout is
> backwards.

Ugh, this stuff makes my head hurt...  How about:

((USHORT*)&p_cm_req->service_id)[3] = p_req->dst_port;
((UCHAR*)&p_cm_req->service_id)[3] = p_req->prot;
((UCHAR*)&p_cm_req->service_id)[4] = 1;

>  Also, the structure is only required to align to a 32-bit boundary,
> which may also be an issue.

The structure is only used by reference, and is set to the address of an 8-byte aligned member of a structure.  It should work fine. :)

> This then leads to whether the structure should
> itself be contained in a union with a UINT64 (for swapping / alignment
> purposes) or defined in network order. Which, of course, makes things that
> much more complex...

I had intended to define the structure in network order (hence why the 'zero' field comes first.)  Maybe I botched it...

> your original patch is probably fine until then

Want me to wrap the #defines with CL_NTOH64, or not bother?

-Fab



More information about the ofw mailing list