Sean Hefty wrote:
+static void ucma_copy_iw_route(struct rdma_ucm_query_route_resp *resp,
+ struct rdma_route *route)
+{
+ struct rdma_dev_addr *dev_addr;
+
+ dev_addr = &route->addr.dev_addr;
+ rdma_addr_get_dgid(dev_addr, (union ib_gid *) &resp->ib_route[0].dgid);
+ rdma_addr_get_sgid(dev_addr, (union ib_gid *) &resp->ib_route[0].sgid);
essentially breaking the query_route call into query_addr, query_path, and
query_gid.
I'm unsure where exactly this change would fit into the newer query model. Are
these values available after rdma_resolve_addr completes?
Yes.
Are the sgid and dgid
the same type of values (e.g. L2 addresses)?
Yes.
If the device does ARP internally,
is the dgid value still set?
No. But only Amso does this, and its old and crusty...
My current implementation for 'query_gid' returns GIDs using an AF_IB address
structure. I'm trying to figure out what structure we should be using to return
the iwarp values -- some other sockaddr, an iw_path_record, other?
I'll have to ponder this. In the past, we've been using the gid.raw
areas to hold these mac addresses...
Here are links to the proposed changes:
http://www.openfabrics.org/git/?p=~shefty/rdma-dev.git;a=commitdiff;h=b87cccdb27
a7e75c0f9e03a9d37593ceab4d4ede
http://www.openfabrics.org/git/?p=~shefty/rdma-dev.git;a=commitdiff;h=1830722bb5
e84451e3b458719cea8c746a2fb6d4
http://www.openfabrics.org/git/?p=~shefty/rdma-dev.git;a=commitdiff;h=0257cc9298
aa70c4bfc1a8c393f970375a897825
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
