Re: [PATCH] RDMA/ucma: Copy iWARP route information on queries.
> For iWARP rdma_cm ids, the "route" information is the L2 src and > next hop addresses. Thanks, applied. -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
On 01/18/2011 05:14 PM, Hefty, Sean wrote: Did this: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg03182.html ever make it upstream? No, but this patch set is still listed in patchworks as new. I just updated the set to 2.6.37 and pushed those changes into an af_ib branch in my git tree. - 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 The reason I asked is that my small change for adding the mac addresses in iwarp routes will cause a merge issue. Roland, do you have plans to merge sean's series soon? -- 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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
> Did this: > > http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg03182.html > > ever make it upstream? No, but this patch set is still listed in patchworks as new. I just updated the set to 2.6.37 and pushed those changes into an af_ib branch in my git tree. - 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
On 01/12/2011 12:32 PM, Roland Dreier wrote: > Did this patch ever make it upstream? I don't see it. Nope, guess it got dropped. It doesn't apply after the IBoE changes -- can you regenerate it? Hey, Did this: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg03182.html ever make it upstream? -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Yes, I will. Thanks, Steve. On 01/12/2011 12:32 PM, Roland Dreier wrote: > Did this patch ever make it upstream? I don't see it. Nope, guess it got dropped. It doesn't apply after the IBoE changes -- can you regenerate it? - R. -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
> Did this patch ever make it upstream? I don't see it. Nope, guess it got dropped. It doesn't apply after the IBoE changes -- can you regenerate it? - R. -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Hey Roland, Did this patch ever make it upstream? I don't see it. On 5/19/2010 5:09 PM, Steve Wise wrote: Roland Dreier wrote: > Roland/Sean, is this ok for 2.6.35? I guess it's fine. What does it give us by itself though? Piece of mind. :) IMO it is a bug fix. -- 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 -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Roland Dreier wrote: > Roland/Sean, is this ok for 2.6.35? I guess it's fine. What does it give us by itself though? Piece of mind. :) IMO it is a bug fix. -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
> Roland/Sean, is this ok for 2.6.35? I guess it's fine. What does it give us by itself though? - R. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Roland/Sean, is this ok for 2.6.35?
Steve Wise wrote:
For iWARP rdma_cm ids, the "route" information is the L2 src and
next hop addresses.
Signed-off-by: Steve Wise
---
drivers/infiniband/core/ucma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index ac7edc2..0498383 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -583,6 +583,16 @@ static void ucma_copy_ib_route(struct
rdma_ucm_query_route_resp *resp,
}
}
+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);
+}
+
static ssize_t ucma_query_route(struct ucma_file *file,
const char __user *inbuf,
int in_len, int out_len)
@@ -621,6 +631,9 @@ static ssize_t ucma_query_route(struct ucma_file *file,
case RDMA_TRANSPORT_IB:
ucma_copy_ib_route(&resp, &ctx->cm_id->route);
break;
+ case RDMA_TRANSPORT_IWARP:
+ ucma_copy_iw_route(&resp, &ctx->cm_id->route);
+ break;
default:
break;
}
--
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
--
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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Sean Hefty wrote: What does AF_UNSPEC imply about the format of the sockaddr? That it depends on the usage..? I came up with this based on using ioctl to manipulate the ARP cache: SIOCSARP - Add a new entry to the ARP cache or modify an existing entry ... arp_ha is a generic socket address structure with sa_family set to AF_UNSPEC and sa_data containing the hardware address (e.g. the 6-byte Ethernet address). The librdmacm should have enough context to interpret the meaning of the query_gid response. - Sean sounds ok to me. -- 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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
>What does AF_UNSPEC imply about the format of the sockaddr? That it depends on the usage..? I came up with this based on using ioctl to manipulate the ARP cache: SIOCSARP - Add a new entry to the ARP cache or modify an existing entry ... arp_ha is a generic socket address structure with sa_family set to AF_UNSPEC and sa_data containing the hardware address (e.g. the 6-byte Ethernet address). The librdmacm should have enough context to interpret the meaning of the query_gid response. - 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
Sean Hefty wrote: I'll have to ponder this. In the past, we've been using the gid.raw areas to hold these mac addresses... There's not too many options with the existing ABI, but the newer query interfaces will give us more flexibility, like variable length addresses, which may make this cleaner. Maybe we can return the L2 address through an AF_UNSPEC sockaddr? What does AF_UNSPEC imply about the format of the sockaddr? -- 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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
>I'll have to ponder this. In the past, we've been using the gid.raw >areas to hold these mac addresses... There's not too many options with the existing ABI, but the newer query interfaces will give us more flexibility, like variable length addresses, which may make this cleaner. Maybe we can return the L2 address through an AF_UNSPEC sockaddr? -- 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
Re: [PATCH] RDMA/ucma: Copy iWARP route information.
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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
>>+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? Are the sgid and dgid
the same type of values (e.g. L2 addresses)? If the device does ARP internally,
is the dgid value still set?
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?
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
RE: [PATCH] RDMA/ucma: Copy iWARP route information.
>For iWARP rdma_cm ids, the "route" information is the L2 src and
>next hop addresses.
>
>Signed-off-by: Steve Wise
>---
>
> drivers/infiniband/core/ucma.c | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
>index ac7edc2..0498383 100644
>--- a/drivers/infiniband/core/ucma.c
>+++ b/drivers/infiniband/core/ucma.c
>@@ -583,6 +583,16 @@ static void ucma_copy_ib_route(struct
>rdma_ucm_query_route_resp *resp,
> }
> }
>
>+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);
This looks good for the current code.
For 2.6.35/36, I've submitted changes to the query operation to support AF_IB,
essentially breaking the query_route call into query_addr, query_path, and
query_gid. I'm guessing that this functionality should be part of the query_gid
call. I'll adjust those patches, but if you get a chance to review the query
changes, I'd appreciate it.
- 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
