> WvGetServiceId swaps the port number in the sockaddr but shouldn't. The
> port number in a sockaddr structure is already in network order. See
> http://msdn.microsoft.com/en-us/library/ff570823(VS.85).aspx, the remarks
> section:
> " All of the data in the SOCKADDR_IN structure, except for the address
> family, must be specified in network-byte-order (big-endian)."
Here's WvGetServiceId:
static UINT64 WvGetServiceId(UINT16 EpType, WV_IO_SOCKADDR_DATA *pAddress)
{
return RtlUlonglongByteSwap(((UINT64)EpType << 16) +
RtlUshortByteSwap(pAddress->SockAddr.In.SinPort));
}
It swaps the port to host order, forms the SID in host order, then swaps the
SID back to network order. This matches the Linux implementation:
static __be64 cma_get_service_id(enum rdma_port_space ps, struct sockaddr *addr)
{
return cpu_to_be64(((u64)ps << 16) + be16_to_cpu(cma_port(addr)));
}
>From the RDMA CM Annex to the IB spec:
"The last two bytes of the Service ID are the ULP port for the IP protocol
number. For
example, for SCTP NFSv4-RDMA default port the Service ID is 0x0000000001840801
(port 2049)"
Based on the example, the port is stored in the service ID in host order (2049
= 0x0801), not network order.
- Sean
_______________________________________________
ofw mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
