Hi
I also agree ref-counting of multicast membership is required.
However, inventing a new API is not required and actually harmful as it
delays availability by requiring every application out there to migrate
to yet another API.
Instead it would be preferable to implement this as part of mad.c
Just saw those warnings when I compiled kernel 2.6.18 on ppc64 using
OFED-1.1-rc7 code with mthca and ehca selected.
CC [M] drivers/infiniband/hw/mthca/mthca_qp.o
drivers/infiniband/hw/mthca/mthca_qp.c: In function `mthca_arbel_post_send':
drivers/infiniband/hw/mthca/mthca_qp.c:1870: warning:
Hi Hal
This patch fixes a bunch of ignored errors in osmtest.c
(plus some cosmetics).
In particular, for some reason osmtest.c doesn't treat
IB_INVALID_PARAMETER as an error.
I couldn't find any reasonable explanation to it.
Perhaps it was usefull while writing osmtest?
Yevgeny
Signed-off-by:
Hi Arlin,
This patch is in OFED-1.1-rc7 and applied during installation.
Regards,
Vladimir
On Tue, 2006-10-10 at 22:50 -0700, Arlin Davis wrote:
Aviram Gutman wrote:
OFED-1.1-rc7 is available on
https://openib.org/svn/gen2/branches/1.1/ofed/releases/
File: OFED-1.1-rc7.tgz
Please report
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 02:13:38 +0200
Maybe I can patch linux to allow SG without checksum?
Dave, maybe you could drop a hint or two on
Hi,
On Wed, Oct 11, 2006 at 11:05:04AM +0200, Michael S. Tsirkin wrote:
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 02:13:38 +0200
Maybe I can patch linux
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 11:05:04 +0200
So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
data will be copied over rather than sent directly.
So why does dev.c have to force set NETIF_F_SG to off then?
Because it's more efficient to
On some of our SUSE 10 machines i found the 127.0.0.2 ip,
but it was pointing to some random Linux site (linux.org)
and has no effect on mpi runs.
In you case the ip point to _real_ machine, it very strange.
Scott Weitzenkamp (sweitzen) wrote:
Aha, I found something in /etc/hosts, thanks for the
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Multiple distinct mcmember_rec queries could get us the same mcast group.
Say MTU 256 and MTU 512 look different but actually will get
same group in practice.
Say 2 clients ask for these 2 queries.
What will be in the ib_sa_mcmember_rec in this
Hi Hal
Fixing a few problems in the multicast test flow,
plus some cosmetics.
Yevgeny
Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
Index: osmt_multicast.c
===
--- osmt_multicast.c(revision 9776)
+++ osmt_multicast.c
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 11:05:04 +0200
So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
data will be copied over rather than
IPoIB discussion aside, some more comments on the API:
+struct ib_multicast {
+ struct ib_sa_mcmember_rec rec;
+ ib_sa_comp_mask comp_mask;
+ int (*callback)(int status,
+ struct ib_multicast *multicast);
+
OK, I'll talk about the ipoib change part here.
Quoting r. Sean Hefty [EMAIL PROTECTED]:
You might be right. But I wander whether we'll regret it later that
we switched to the slower generic thing when we already had a stable,
streamlined version.
To be direct, I'm not sure that I'd call
Michael S. Tsirkin wrote:
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Add an ib_multicast module to perform reference counting of multicast
join / leave requests. Modify ib_ipoib to use the multicast module.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
On the ipoib change - whya re we doing it
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
The ipoib change is a must to allow for user space consumers to
join/leave groups whose MGID is of IP multicast origin.
So one process can have its IP mulitcast traffic carried out by ipoib
and another process can use librdmacm to join the same
Or Gerlitz wrote:
Michael S. Tsirkin wrote:
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Add an ib_multicast module to perform reference counting of multicast
join / leave requests. Modify ib_ipoib to use the multicast module.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
On the ipoib
On Wed, 2006-10-11 at 04:08, Yevgeny Kliteynik wrote:
Hi Hal
This patch fixes a bunch of ignored errors in osmtest.c
(plus some cosmetics).
In particular, for some reason osmtest.c doesn't treat
IB_INVALID_PARAMETER as an error.
I couldn't find any reasonable explanation to it.
Now that
Eitan Zahavi wrote:
If the tracking (ref counting) was done at the MAD level - no change to
IPoIB would have been required ...
Maybe.
You could also implement all the ib stack core in one module...
The openib designers have chosen not to do so and rather break it into
smaller modules namely
Michael S. Tsirkin wrote:
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
The ipoib change is a must to allow for user space consumers to
join/leave groups whose MGID is of IP multicast origin.
So one process can have its IP mulitcast traffic carried out by ipoib
and another process can use
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
Let's see it get some use before switching a basic component over.
This porting relies on Sean's work to allow for joining/leaving IP
Multicast mcast groups from user space. And anyway, when you expose
something to user space, you might not see the
Michael S. Tsirkin wrote:
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
This porting relies on Sean's work to allow for joining/leaving IP
Multicast mcast groups from user space. And anyway, when you expose
something to user space, you might not see the usage as it can be not
an open source
On 10/9/06, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
I'm trying to build a network device driver supporting a very large MTU
(around 64K)
on top of an infiniband connection, and I've hit a couple of issues I'd
appreciate some feedback on:
Does it mean you are implementing IPoIB RC? Cool
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
to make the testing
of uCMA consumers robust, applying this patch set on the for-2.6.20
branch of the IB git tree is essential.
Not really.
Just build a git tree and put whatever you want there.
--
MST
___
Hi Or,
Maybe I did not explain myself right.
The idea is not to implement it in the mad.c code but rather to
implement it at the lowest level:
The problem with a new API is that a single ULP/applications which does
direct umad or QP1 access will break the reference count.
Implementing at the
On Wed, 2006-10-11 at 06:23, Yevgeny Kliteynik wrote:
Hi Hal
Fixing a few problems in the multicast test flow,
plus some cosmetics.
Yevgeny
Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
Thanks. Applied. See question below...
Index: osmt_multicast.c
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct sock *sk = sock-sk;
if (!(sk-sk_route_caps NETIF_F_SG) ||
Just saw those warnings when I compiled kernel 2.6.18 on ppc64 using
OFED-1.1-rc7 code with mthca and ehca selected.
CC [M] drivers/infiniband/hw/mthca/mthca_qp.o
drivers/infiniband/hw/mthca/mthca_qp.c: In function `mthca_arbel_post_send':
drivers/infiniband/hw/mthca/mthca_qp.c:1870:
On Wed, Oct 11, 2006 at 04:21:41PM +0200, Or Gerlitz wrote:
On 10/9/06, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
I'm trying to build a network device driver supporting a very large MTU
(around 64K)
on top of an infiniband connection, and I've hit a couple of issues I'd
appreciate
Arlin,
I see now that the uDAPL CMA provider code uses the MTU 1:1 as returned
by the SM in the path, so if the env is made of the Mellanox PCI-X HCA
there can be big BW drop, etc... we have discussed that.
I wonder how are you overcoming this when running Intel MPI w. OFED 1.0?
I understand
Vlad, do you have symbol cm_issue_drep in any .ko files, because I
don't. Looks like the patch is not getting compiled in for some reason.
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Vladimir Sokolovsky
You checked SUSE 10 or SLES 10, aren't those different distros?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Pavel Shamis (Pasha) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006 3:09 AM
To: Scott
Michael S. Tsirkin wrote:
It is somewhat unfortunate that we are duplicating the SA logic
at the endnode in kernel memory here - current sa module has
the advantage in that it just packs all data into a mad and sends it out.
Something to think about.
What alternative do you propose? The SA
We've installed four SLES10 machines so far, and they all have the
127.0.0.2 myhostname entry.
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Pavel Shamis (Pasha) [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
Eitan Zahavi wrote:
Maybe I did not explain myself right.
The idea is not to implement it in the mad.c code but rather to
implement it at the lowest level:
The problem with a new API is that a single ULP/applications which does
direct umad or QP1 access will break the reference count.
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: [openib-general] [RFC] [PATCH 2/7] ib_multicast 2.6.20: add
ib_multicast module to track join requests from the same port
Michael S. Tsirkin wrote:
It is somewhat unfortunate that we are duplicating the SA logic
at the endnode in
Here is some link about SuSE's bugs related to 127.0.0.2
https://bugzilla.novell.com/show_bug.cgi?id=165269
Check your SuEe auto-install stuff. It is possible that you have some
broken configuration in it.
Scott Weitzenkamp (sweitzen) wrote:
We've installed four SLES10 machines so far, and
Michael S. Tsirkin wrote:
Why is this even a good idea?
If you are looking for reasons using mutlicast module in ipoib is good, I
would
say blocking unpriviledged userspace from joining IPoIB GID and snoopig on all
mcast traffic sounds like a better idea. BTW, Sean, I think this is
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Finally, the patch in question also seems to introduce more cleanups and
such. It would be less controversial if it was just an API change.
The cleanups are part of the change. Once ib_join_multicast() has been
invoked,
ib_free_multicast() must
Hi Scott,
You can check OFED compilation log file to see if this patch was applied
and compiled.
To get the relevant log file:
ls -ltr /tmp/OFED*log | tail -2
One of them will be the compilation log.
Search for sean_cm_drep_on_not_found.patch inside...
Regards,
Vladimir
On
Michael S. Tsirkin wrote:
+struct ib_multicast {
+ struct ib_sa_mcmember_rec rec;
+ ib_sa_comp_mask comp_mask;
+ int (*callback)(int status,
+ struct ib_multicast *multicast);
+ void*context;
Sean Hefty wrote:
Why is it a bad idea? The architecture allows this. However, none of
the proposed patches allows a userspace app to join an ipoib multicast
group.
Just to make sure, by ipoib multicast group you mean an MGID which is
derives from an IP Multicast address and the routing
Sean Hefty wrote:
Michael S. Tsirkin wrote:
Why is this even a good idea?
If you are looking for reasons using mutlicast module in ipoib is good, I
would
say blocking unpriviledged userspace from joining IPoIB GID and snoopig on
all
mcast traffic sounds like a better idea. BTW, Sean,
Or Gerlitz wrote:
Just to make sure, by ipoib multicast group you mean an MGID which is
derives from an IP Multicast address and the routing info on the device
this address/subnets is routed to (ie the ipoib device pkey which you
can get from the broadcast MAC of this device)?
I mean a
I mean SLES10.
(yes it's different distros)
Scott Weitzenkamp (sweitzen) wrote:
You checked SUSE 10 or SLES 10, aren't those different distros?
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Pavel Shamis
Michael S. Tsirkin wrote:
We already do state tracking to join/leave groups properly.
It would be easier to review this change if you left killing off
mcast-done and other such improvements for a separate patch.
The multicast module does reference counting and completion handling for us.
Eitan Zahavi wrote:
The point is not the fact you need to layer. But you can not enforce ref
counting by adding a top layer everybody can bypass.
It simply breaks on the first client that goes directly to the lower level.
Do you have a solution for this problem?
The layer you need to add is
Hal Rosenstock wrote:
On Wed, 2006-10-11 at 12:24, Eitan Zahavi wrote:
Sean Hefty wrote:
Michael S. Tsirkin wrote:
Why is this even a good idea?
If you are looking for reasons using mutlicast module in ipoib is good, I
would
say blocking unpriviledged userspace from
On 10/10/06, Sean Hefty [EMAIL PROTECTED] wrote:
Add missing support for RDMA_PS_UDP. This allows the use of UD QPs
through the rdma_cm, which provides address translation services
over IB, even if not all RDMA transports support UD.
To the best of my knowledge every single iWARP RNIC
fully
The point is not the fact you need to layer. But you can not enforce ref
counting by adding a top layer everybody can bypass.
It simply breaks on the first client that goes directly to the lower level.
Do you have a solution for this problem?
The layer you need to add is BELOW the current
User level code can be run by root. It can access QP1 and bypass your
nice API.
Also you ignore current kernel implementations that exist and already
perform QP1 access via the SA client code in the kernel.
Sean Hefty wrote:
Eitan Zahavi wrote:
The point is not the fact you need to layer.
On Wed, 2006-10-11 at 12:24, Eitan Zahavi wrote:
Sean Hefty wrote:
Michael S. Tsirkin wrote:
Why is this even a good idea?
If you are looking for reasons using mutlicast module in ipoib is good, I
would
say blocking unpriviledged userspace from joining IPoIB GID and snoopig on
Eitan Zahavi wrote:
User level code can be run by root. It can access QP1 and bypass your nice
API. Also you ignore current kernel implementations that exist and already
perform QP1 access via the SA client code in the kernel.
Yep - and that same app can, today, delete the multicast groups
http://openib.org/bugzilla/show_bug.cgi?id=263
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
http://openib.org/bugzilla/show_bug.cgi?id=263
[EMAIL PROTECTED] changed:
What|Removed |Added
Version|1.1rc6 |1.1rc7
--- Comment #2 from
At 02:46 AM 10/11/2006, Michael S. Tsirkin wrote:
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 11:05:04 +0200
So, it seems that if I set NETIF_F_SG but clear
We aren't using SLES auto-install. But I did google for SLES
127.0.0.2 and found this at
http://www.novell.com/documentation/novellaudit20/readme/novellaudit20_r
eadme.html:
2.8 SLES 10 hosts File
SLES 10 includes two localhost entries in the /etc/hosts file:
127.0.0.1 and 127.0.0.2
Hi Michael,
I'm investigating some of the performance differences between the new
implementation of SDP and the old. The profiles are substantially
different, with the new spending much more time polling than the old
did. I'm not sure if this is a direct effect or secondary due to
something
Sean Hefty wrote:
Eitan Zahavi wrote:
User level code can be run by root. It can access QP1 and bypass your nice
API. Also you ignore current kernel implementations that exist and already
perform QP1 access via the SA client code in the kernel.
Yep - and that same app can, today,
Eitan If the tracking (ref counting) was done at the MAD level -
Eitan no change to IPoIB would have been required ...
It doesn't seem very feasible to implement a complete local copy of
the SA (in the kernel no less) so that we can allow unprivileged
processes to send on QP1.
- R.
Eitan Hi Or, Maybe I did not explain myself right. The idea is
Eitan not to implement it in the mad.c code but rather to
Eitan implement it at the lowest level: The problem with a new
Eitan API is that a single ULP/applications which does direct
Eitan umad or QP1 access will
Michael Why is this even a good idea? If you are looking for
Michael reasons using mutlicast module in ipoib is good, I would
Michael say blocking unpriviledged userspace from joining IPoIB
Michael GID and snoopig on all mcast traffic sounds like a better
Michael idea. BTW,
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct sock *sk
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 17:01:03 +0200
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct
On Wed, 11 Oct 2006 21:11:38 +0100
Steven Whitehouse [EMAIL PROTECTED] wrote:
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
Or Its not a rush its a move for enabling user space code that
Or can offload IP Multicast. We have a library doing that which
Or is coded over the gen1 stack and is now in porting for the
Or gen2 stack.
OK -- I would like to hear your experiences porting on top of this.
- R.
Eitan User level code can be run by root. It can access QP1 and
Eitan bypass your nice API. Also you ignore current kernel
Eitan implementations that exist and already perform QP1 access
Eitan via the SA client code in the kernel.
root can already do anything at all so I don't
Roland Dreier wrote:
Yes, I would like to see another consumer, just to get a sanity check
that you have implemented the right thing.
I think aiming for 2.6.20 is reasonable, but I'm fine if this doesn't end up
making it. I'd like to get it into a branch targeting some kernel release
(even
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
On Wed, 11 Oct 2006 21:11:38 +0100
Steven Whitehouse [EMAIL PROTECTED] wrote:
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven
Eitan Zahavi wrote:
So if it is then there is no problem sniffing it and refcounting.
The MADs cannot simply be sniffed and counted. MADs which affect the same
multicast group should not always be sent. Join operations must be serialized
against leave operations, especially when the
Yes, the patch is being applied. Not sure why cm_issue_drep is not
there though...
Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
-Original Message-
From: Vladimir Sokolovsky [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 11, 2006
http://openib.org/bugzilla/show_bug.cgi?id=279
Summary: OFED: warning when building uverbs_main.c on RHEL4 U3
Product: OpenFabrics Linux
Version: 1.1rc7
Platform: Other
OS/Version: RHEL 4
Status: NEW
Severity: normal
O
You might want to try ignoring the check in dev.c and testing
to see if there is a performance gain. It wouldn't be hard to test
a modified version and validate the performance change.
Yes. With my patch, there is a huge performance gain by increasing MTU to 64K.
And it seems the
Thanks, queued for 2.6.19
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 23:23:39 +0200
With my patch, there is a huge performance gain by increasing MTU to 64K.
And it seems the only way to do this is by S/G.
Numbers?
___
openib-general mailing list
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
O
You might want to try ignoring the check in dev.c and testing
to see if there is a performance gain. It wouldn't be hard to test
a modified version and validate the
http://openib.org/bugzilla/show_bug.cgi?id=263
--- Comment #3 from [EMAIL PROTECTED] 2006-10-11 15:13 ---
In both cases the final crash seems to be in the call
spin_lock_irqsave(priv-lock, flags);
in path_rec_completion(). This would seem to indicate some sort of memory
http://openib.org/bugzilla/show_bug.cgi?id=263
--- Comment #4 from [EMAIL PROTECTED] 2006-10-11 15:25 ---
OK, most likely dev_queue_xmit() is returning an error because the device is
down, but that should be OK. I guess we have a race somewhere with up/downing
the device at the same
Sean Hefty wrote:
+ int (*callback)(int status,
+ struct ib_multicast
+ *multicast),
+ void *context);
+
Is this
http://openib.org/bugzilla/show_bug.cgi?id=263
--- Comment #5 from [EMAIL PROTECTED] 2006-10-11 16:35 ---
Scott, could you add debug_level=1 to the ib_ipoib module flags and rerun one
of these tests? That will generate a boatload of logging output, but I'd just
like to see the last
Re-write all cma error cases to simplify code. Splitting
it as multiple patches (one per routine) in case some are
found not required (in which case, later ones may apply
with a fuzz).
Signed-off-by: Krishna Kumar [EMAIL PROTECTED]
___
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -389,16 +389,16 @@ int rdma_create_qp(struct rdma_cm_id *id
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1276,14 +1276,12 @@ static void cma_work_handler(void *data)
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1435,13 +1435,10 @@ int rdma_resolve_route(struct rdma_cm_id
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1348,13 +1348,12 @@ int rdma_set_ib_paths(struct rdma_cm_id
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1600,13 +1600,10 @@ int rdma_resolve_addr(struct rdma_cm_id
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -2054,13 +2054,10 @@ int rdma_accept(struct rdma_cm_id *id, s
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1542,8 +1542,10 @@ static int cma_resolve_loopback(struct r
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -2389,13 +2389,10 @@ static int cma_init(void)
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1453,19 +1453,19 @@ static int cma_bind_loopback(struct rdma
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1963,11 +1963,7 @@ int rdma_connect(struct rdma_cm_id *id,
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -2288,14 +2288,15 @@ static void cma_add_one(struct ib_device
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1208,13 +1208,13 @@ int rdma_listen(struct rdma_cm_id *id, i
diff -ruNp org/drivers/infiniband/core/cma.c new/drivers/infiniband/core/cma.c
--- org/drivers/infiniband/core/cma.c 2006-10-09 16:40:04.0 +0530
+++ new/drivers/infiniband/core/cma.c 2006-10-09 16:52:03.0 +0530
@@ -1165,11 +1165,7 @@ static void cma_listen_on_dev(struct rdm
93 matches
Mail list logo
