RE: [PATCH 2/2] rdma/cm: allow user to specify IP to DGID mapping

Sean Hefty
2009-10-08T06:46:24Z

>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.