> 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.htm
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 | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/co
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 g
> 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
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 m
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 "unsubs
> 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 majord
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 fro
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
M
> 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 linu
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/drive
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 addre
>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_fami
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 thi
>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
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
>>+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
>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/c
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
19 matches
Mail list logo
