>Yep, not sure how you handle the listening side without port
>conflicts?? But that doesn't seem to be a huge problem. TBH - since
>ACM is kinda its own little world, it could just use a seperate
>service ID space from RDMA CM?
I'm not sure how to handle the port space yet. The port space is specified when
the rdma_cm_id is created. I don't think there's an immediate need to change
anything on the listen side, but if we add AF_IB, then adding RDMA_PS_IB may
make sense. This could be the full 64-bit service ID. (We can determine the
right name for AF_IB / AF_GID based on what's actually in the structure.)
>> The following information should be known after calling
>> rdma_resolve_addr: sgid, dgid, pkey, source port/sid, destination
>> port/sid. The address structure for AF_IB should be defined to
>> capture this information. (The port / service ID needs to be worked
>> out.)
>
>Yes, that seems great..
On second thought, I'm not sure about _needing_ the pkey. My first draft of
this is:
struct sockaddr_ib {
unsigned short int ib_family;
__u16 reserved;
union ib_gid gid;
__be64 ib_service_id;
};
Although I considered dividing the service id and putting the low order bytes
where reserved is, or only supporting the RDMA IP CM service ID format, possibly
using sockaddr_in6 directly.
>What API would you use to pass the PR data?
API at which level?
>What do you think of a 'rdma_get_addr_info' that could be where libacm
>hooks?
I have no objections to extending the librdmacm API.
>> Would this approach combined with the ability to set the route work for
>> everyone?
>
>'set the route' ?
Pass the path record to the kernel. This piece is still missing to allow user
space to own the policy for obtaining path information.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
