>Right :) I just don't understand why you think AF_IB/RDMA_PS_TCP has
>to be a supported combination.
I don't see any reason to prevent it. It works unless a specific check is added
in the kernel to prevent it. Do I think it absolutely must be supported? No -
so I don't have a strong disagreement on this.
It just seems like the code ends up as either:
if (sa_family == AF_IB) {
if (ps != PS_IB)
fail;
use_ps = get_ps(sid, mask);
}
or
if (sa_family == AF_IB) {
if (get_ps(sid, mask) != ps)
fail;
use_ps = ps;
}
>Is there some use case you see where having RDMA_PS_TCP/UDP work with
>AF_IB is an advantage?
Consider UDP, an application can create an id and join multicast groups using
AF_INET, AF_INET6, and/or AF_IB - whatever addressing scheme is most convenient.
What I have right now for user space support requires application changes to
make use of AF_IB anyway, so only supporting PS_IB isn't a big deal. The
benefit to existing code is limited to user space path record queries.
- Sean
--
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
