[openib-general] Any chance to get 32-Bit libraries on SLES9 x86_64?

[Bub Thomas]

Title: Any chance to get 32-Bit libraries on SLES9 x86_64?






Is there any chance/trick to get 32-Bit Libraries build and usable on SLES9 x86_64?

When I installed OFED-1.1-rc4 I get:

 

WARNING: sysfsutils 32-bit version is required to build 32-bit libibverbs package.

WARNING: Skiping build of 32-bit libraries.

I googled around and didn’t find any sysfsutils 32-bit for SLES9.

I now that tit is working under SLES10 b  ut our customer base is on SLES9 and very conservative when it comes down to using the latest and greates Os/distribution.

Thomas




Thomas Bub
Grass Valley Germany GmbH
Brunnenweg 9
64331 Weiterstadt, Germany
Tel: +49 6150 104 147
Fax: +49 6150 104 656
Email: [EMAIL PROTECTED]
www.GrassValley.com







___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Robert Walsh]

> Changes are expected to be tested before you commit.
> This is really maintainer's responsibility, please take it seriously.

I have to take exception here.  It's only possible for us to make a 
serious attempt at doing something like this if OFED takes a more 
serious approach to the idea of what a "release candidate" is.  Throwing 
out an RC in one day was not a good idea; nor was changing an API in the 
middle of the process.  We're lucky that's all that broke.

Regards,
  Robert.

___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Michael S. Tsirkin]

Quoting r. Robert Walsh <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > I installed RC5 and now it just hangs, 
> 
> Wow - we can't even get RC5 to build here.  What distro are you running?
> 
> I've tried this on RC4 + a fixed libipathverbs package and it runs OK
> (although it does take a while, which might explain the hang you were
> seeing.)
> 
> But mostly I'm curious how you get RC5 to build at all.
> 
> We really really really shouldn't be attempting to turn RC's around as
> fast as RC4 to RC5 went: we basically had about enough time to throw a
> patch together without being able to do much testing.

Changes are expected to be tested before you commit.
This is really maintainer's responsibility, please take it seriously.

-- 
MST

___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Michael S. Tsirkin]

Well, it looks like the libipathverbs that went into 1.1 branch was botched.
How come?
Please note that Mellanox for one is unable to test libipathverbs at all.
libipathverbs maintainers, please, try to fix by Sunday.
And please, test the changes before you commit them.


Quoting r. Robert Walsh <[EMAIL PROTECTED]>:
Subject: Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Woodruff, Robert J wrote:
> Robert Walsh wrote, 
>> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
>> 4730: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
>> iters=1 | duplex=0 | cma=0 |
>> 4730: Local address:  LID 0x03, QPN 0x001d, PSN 0x9e070c RKey
> 0x2302400
>> VAddr 0x2a95dd3480
>> 4730: Remote address: LID 0x04, QPN 0x001e, PSN 0x2bd6ba, RKey
> 0x2402500
>> VAddr 0x2a95c85480
>> 4730:main: Completion with error at client:
>> 4730:main: Failed status 9: wr_id 3
>> 4730:main: scnt=7584, ccnt=6584
>> [EMAIL PROTECTED] bin]$  
> 
>> Hi Woody,
> Robert Walsh wrote, 
>> When RC4 is available, there should be a patch in there that will fix
>> this.  Can you let us know if you continue to see problems?
> 
>> Regards,
>> Robert.
> 
> I installed RC5 and now it just hangs, 
> 
> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
> 4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
> iters=1 | duplex=0 | cma=0 |
> 4702: Local address:  LID 0x03, QPN 0x000d, PSN 0xf1b711 RKey 0x1101200
> VAddr 0x2a95dc8480
> 4702: Remote address: LID 0x04, QPN 0x000d, PSN 0xe62247, RKey 0x1101200
> VAddr 0x2a95c7c480
> hangs here and have to cntrl-c the test.
> 
> 
> Intel MPI also fails with, 
> # Barrier
> [1][rdma_iba.c:260] Intel MPI fatal error: DTO operation completed with
> error. status=0x8. cookie=0x514ee0
> rank 1 in job 4  rkl-13_32779   caused collective abort of all ranks
>   exit status of rank 1: killed by signal 9 

Hi Woody,

So, we built everything using RC5 plus the libipathverbs from subversion
and we were successfully able to run ib_rdma_bw (with your arguments
above) and Intel MPI (a simple MPI hello world program).  I'm going to
continue testing with the Intel MPI testsuite and some applications ISV
applications.

I'll keep you informed.

Regards,
 Robert.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBRQoATfzvnpzTd9fxAQLUKQf9E1ps9XbbXplMm6+5O/XDdlWF0BQws1SC
L/aGygh34fZSkpGmCrfze3HhsaOqasu9gUOsJQ89jX6pKNkv4tJAxSJCr+n+bdG3
21Bqr9gcM0MbzrDvOcUDHqvnmC0THlCf0XhikjKg/FJR1e48BIiAOFUzfi0VvI36
G1ZtD8xZXydOfWq7Z4xvyf9Y3qNPIeSKR2JZGJQoGHjxY4+vcteK0UVHfic1Bgpy
9uql47af6tncN+CazYcwf8xnHegiDr34iEEre5wUz//Qy62j8JNPnxhit0W9lXij
zFszTkOHQeibxbFWi9ZRyigTmHanxxRUuznW54NL8NIF30jhnmcksQ==
=06gu
-END PGP SIGNATURE-

___
openfabrics-ewg mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openfabrics-ewg

-- 
MST

___
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

Re: [openib-general] [openfabrics-ewg] [PATCH] OFED 1.1-rc3 is ready

[Scott Weitzenkamp (sweitzen)]

> > I installed RC5 and now it just hangs, 
> 
> Wow - we can't even get RC5 to build here.  What distro are 
> you running?
> 
> I've tried this on RC4 + a fixed libipathverbs package and it runs OK
> (although it does take a while, which might explain the hang you were
> seeing.)
> 
> But mostly I'm curious how you get RC5 to build at all.
> 
> We really really really shouldn't be attempting to turn RC's around as
> fast as RC4 to RC5 went: we basically had about enough time to throw a
> patch together without being able to do much testing.

I think many of us are in agreement, before RC6 I propose we only check
in critical work on the release branch, and get some time in to
thoroughly test RC5.  Non-critical fixes can wait until after 1.1.  I
personally would like a week to test RC5.  I feel like we had forgotten
what the E in OFED stands for, if we have to slip the release schedule
to make this code really stable I'm in favor of it.

Scott

___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Roland Dreier]

Hal> I see now. It does refer to full members. I know this used to
Hal> be right (with perhaps the exception of rate which was what
Hal> the email referred to). Is my memory wrong ?

I think that IPoIB has always used the attributes required by the IBA
spec to create a multicast group, but not all the attributes required
by the IPoIB spec.

 - R.

___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Robert Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Woodruff, Robert J wrote:
> Robert Walsh wrote, 
>> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
>> 4730: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
>> iters=1 | duplex=0 | cma=0 |
>> 4730: Local address:  LID 0x03, QPN 0x001d, PSN 0x9e070c RKey
> 0x2302400
>> VAddr 0x2a95dd3480
>> 4730: Remote address: LID 0x04, QPN 0x001e, PSN 0x2bd6ba, RKey
> 0x2402500
>> VAddr 0x2a95c85480
>> 4730:main: Completion with error at client:
>> 4730:main: Failed status 9: wr_id 3
>> 4730:main: scnt=7584, ccnt=6584
>> [EMAIL PROTECTED] bin]$  
> 
>> Hi Woody,
> Robert Walsh wrote, 
>> When RC4 is available, there should be a patch in there that will fix
>> this.  Can you let us know if you continue to see problems?
> 
>> Regards,
>> Robert.
> 
> I installed RC5 and now it just hangs, 
> 
> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
> 4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
> iters=1 | duplex=0 | cma=0 |
> 4702: Local address:  LID 0x03, QPN 0x000d, PSN 0xf1b711 RKey 0x1101200
> VAddr 0x2a95dc8480
> 4702: Remote address: LID 0x04, QPN 0x000d, PSN 0xe62247, RKey 0x1101200
> VAddr 0x2a95c7c480
> hangs here and have to cntrl-c the test.
> 
> 
> Intel MPI also fails with, 
> # Barrier
> [1][rdma_iba.c:260] Intel MPI fatal error: DTO operation completed with
> error. status=0x8. cookie=0x514ee0
> rank 1 in job 4  rkl-13_32779   caused collective abort of all ranks
>   exit status of rank 1: killed by signal 9 

Hi Woody,

So, we built everything using RC5 plus the libipathverbs from subversion
and we were successfully able to run ib_rdma_bw (with your arguments
above) and Intel MPI (a simple MPI hello world program).  I'm going to
continue testing with the Intel MPI testsuite and some applications ISV
applications.

I'll keep you informed.

Regards,
 Robert.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBRQoATfzvnpzTd9fxAQLUKQf9E1ps9XbbXplMm6+5O/XDdlWF0BQws1SC
L/aGygh34fZSkpGmCrfze3HhsaOqasu9gUOsJQ89jX6pKNkv4tJAxSJCr+n+bdG3
21Bqr9gcM0MbzrDvOcUDHqvnmC0THlCf0XhikjKg/FJR1e48BIiAOFUzfi0VvI36
G1ZtD8xZXydOfWq7Z4xvyf9Y3qNPIeSKR2JZGJQoGHjxY4+vcteK0UVHfic1Bgpy
9uql47af6tncN+CazYcwf8xnHegiDr34iEEre5wUz//Qy62j8JNPnxhit0W9lXij
zFszTkOHQeibxbFWi9ZRyigTmHanxxRUuznW54NL8NIF30jhnmcksQ==
=06gu
-END PGP SIGNATURE-

___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Hal Rosenstock]

On Thu, 2006-09-14 at 20:52, Roland Dreier wrote:
> Hal> That indeed is true for create. However, send only members
> Hal> can never create a group (only full members can do this). Am
> Hal> I confusing this with a different patch which went by ?
> 
> Yes, I think so.  Look back to the beginning of this thread for the
> initial report of the problem.

I see now. It does refer to full members. I know this used to be right
(with perhaps the exception of rate which was what the email referred
to). Is my memory wrong ?

-- Hal


___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Roland Dreier]

Hal> That indeed is true for create. However, send only members
Hal> can never create a group (only full members can do this). Am
Hal> I confusing this with a different patch which went by ?

Yes, I think so.  Look back to the beginning of this thread for the
initial report of the problem.

 - R.

___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Hal Rosenstock]

On Thu, 2006-09-14 at 20:35, Roland Dreier wrote:
> Hal> Are you referring to create or join here ?
> 
> The whole thing is about new groups that IPoIB creates.  Currently we
> don't specify HopLimit, MTU or Rate, and the IPoIB RFC says we should.

That indeed is true for create. However, send only members can never
create a group (only full members can do this). Am I confusing this with
a different patch which went by ?

-- Hal


___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Robert Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> I installed RC5 and now it just hangs, 

Wow - we can't even get RC5 to build here.  What distro are you running?

I've tried this on RC4 + a fixed libipathverbs package and it runs OK
(although it does take a while, which might explain the hang you were
seeing.)

But mostly I'm curious how you get RC5 to build at all.

We really really really shouldn't be attempting to turn RC's around as
fast as RC4 to RC5 went: we basically had about enough time to throw a
patch together without being able to do much testing.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBRQn2QPzvnpzTd9fxAQJFogf/fJidIu6UVaSTbGMyia66kgYrtrL5lvtr
FcmyBI01SbjOUnd9rfejt0y1IeN+1O88wBBJBnQPSi3aRUmCufuGYRWM9T2ZXmw8
PxCLyN44AvyF/B6SUfwr8ygXcAQ2nJPvxfdpnEyFlTxBf5gatDg00YiSRu88NtxR
5DrDsK/8OSpy6j0lRVoB7hJh2cs74NhtXawvvzlmGBI4ZhoTmifNPSmPnXwMHJ7+
a4A+dK1cSqjLFUXDh6WPIM5OHS6bKbQeKQ3J4H+I99uK+5n3fb/9CP+Z/aZ3/JEG
Qg9dfgsF4onKNBDsXPoGHjI1iU+FOghLFZCTvYXirkqXPgVsTAVK5A==
=hwu5
-END PGP SIGNATURE-

___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Roland Dreier]

Hal> Are you referring to create or join here ?

The whole thing is about new groups that IPoIB creates.  Currently we
don't specify HopLimit, MTU or Rate, and the IPoIB RFC says we should.

___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Hal Rosenstock]

On Thu, 2006-09-14 at 17:11, Roland Dreier wrote:
>  > Hmm, IPoIB does not seem to copy anything except the pkey.
>  > Looks like a compliance issue.
> 
> Well, the only MUST attributes we seem to be missing are HopLimit and MTU
> (P_Key, Q_Key and SL are all copied from the broadcast group when
> creating a new multicast group).

Are HopLimit and MTU needed for join ? I thought it was fine to wildcard
those for a join. If they are specified though, they do need to match
the group.

>  > Specifically, I'm not sure what "other attributes" are, but I think
>  > this should include the static rate. Right?
> 
> I guess we should definitely do HopLimit and MTU, since those are
> MUSTs.

Are you referring to create or join here ?

>   The only other attribute we look at is Rate, so I guess we
> should set that also.

The rate should be set properly (with the rate selector set to exactly)
in the response regardless of whether it was set in the request (e.g.
wildcarded or not).

-- Hal

>  - R.
> 
> ___
> 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
> 


___
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

[openib-general] [RFC] [PATCH] ib_cm: send DREP in response to unmatched DREQ

[Sean Hefty]

Currently a DREP is only sent in response to a DREQ if a connection
has been found matching the DREQ, and it is in the proper state.  Once
a DREP is sent, the local connection moves into timewait.  Duplicate
DREQs received while in this state result in re-sending the DREP.

However, it's likely that the local connection will enter and exit
timewait before the remote side times out a lost DREP and resends a DREQ.
There are a couple possible solutions to this.  One is to increase how
long a connection remains in timewait, by multiplying its wait time by
max_cm_retries.  This can greatly increase the timewait state before a QP
can be re-used when CM messages are not lost.

An alternative is to send a DREP in response to a DREQ, even if a local
connection is not found, which is what this patch does.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Index: cm.c
===
--- cm.c(revision 9490)
+++ cm.c(working copy)
@@ -1900,6 +1900,32 @@ out: spin_unlock_irqrestore(&cm_id_priv-
 }
 EXPORT_SYMBOL(ib_send_cm_drep);
 
+static int cm_issue_drep(struct cm_port *port,
+struct ib_mad_recv_wc *mad_recv_wc)
+{
+   struct ib_mad_send_buf *msg = NULL;
+   struct cm_dreq_msg *dreq_msg;
+   struct cm_drep_msg *drep_msg;
+   int ret;
+
+   ret = cm_alloc_response_msg(port, mad_recv_wc, &msg);
+   if (ret)
+   return ret;
+
+   dreq_msg = (struct cm_dreq_msg *) mad_recv_wc->recv_buf.mad;
+   drep_msg = (struct cm_drep_msg *) msg->mad;
+
+   cm_format_mad_hdr(&drep_msg->hdr, CM_DREP_ATTR_ID, dreq_msg->hdr.tid);
+   drep_msg->remote_comm_id = dreq_msg->local_comm_id;
+   drep_msg->local_comm_id = dreq_msg->remote_comm_id;
+
+   ret = ib_post_send_mad(msg, NULL);
+   if (ret)
+   cm_free_msg(msg);
+
+   return ret;
+}
+
 static int cm_dreq_handler(struct cm_work *work)
 {
struct cm_id_private *cm_id_priv;
@@ -1911,8 +1937,10 @@ static int cm_dreq_handler(struct cm_wor
dreq_msg = (struct cm_dreq_msg *)work->mad_recv_wc->recv_buf.mad;
cm_id_priv = cm_acquire_id(dreq_msg->remote_comm_id,
   dreq_msg->local_comm_id);
-   if (!cm_id_priv)
+   if (!cm_id_priv) {
+   cm_issue_drep(work->port, work->mad_recv_wc);
return -EINVAL;
+   }
 
work->cm_event.private_data = &dreq_msg->private_data;
 


___
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

Re: [openib-general] Fwd: IPoIB Multicast

[Roland Dreier]

 > Hmm, IPoIB does not seem to copy anything except the pkey.
 > Looks like a compliance issue.

Well, the only MUST attributes we seem to be missing are HopLimit and MTU
(P_Key, Q_Key and SL are all copied from the broadcast group when
creating a new multicast group).

 > Specifically, I'm not sure what "other attributes" are, but I think
 > this should include the static rate. Right?

I guess we should definitely do HopLimit and MTU, since those are
MUSTs.  The only other attribute we look at is Rate, so I guess we
should set that also.

 - R.

___
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

Re: [openib-general] [PATCH for-2.6.18] Re: [PATCH] IB/cma: add rdma_establish

[Roland Dreier]

OK, I put this in 2.6.18 since I had a few other fixes that I thought
should go into 2.6.18 too.  It was a close call between merging this
now or putting it into 2.6.19 and waiting for 2.6.18.1, but I don't
think it matters much either way.

 - R.

___
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

[openib-general] [GIT PULL] please pull infiniband.git

[Roland Dreier]

Linus, please pull from

master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus

This tree is also available from kernel.org mirrors at:

git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git 
for-linus

This contains a few last-minute fixes -- a couple of one-liners, and a
panic fix that turns out to be pure deletions:

Eli Cohen:
  IPoIB: Retry failed send-only multicast group joins

Ishai Rabinovitz:
  IB/srp: Don't schedule reconnect from srp

Michael S. Tsirkin:
  RDMA/cma: Increase the IB CM retry count in CMA

 drivers/infiniband/core/cma.c  |2 +-
 drivers/infiniband/ulp/ipoib/ipoib_multicast.c |1 +
 drivers/infiniband/ulp/srp/ib_srp.c|   14 --
 3 files changed, 2 insertions(+), 15 deletions(-)


diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index d6f99d5..5d625a8 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -49,7 +49,7 @@ MODULE_DESCRIPTION("Generic RDMA CM Agen
 MODULE_LICENSE("Dual BSD/GPL");
 
 #define CMA_CM_RESPONSE_TIMEOUT 20
-#define CMA_MAX_CM_RETRIES 3
+#define CMA_MAX_CM_RETRIES 15
 
 static void cma_add_one(struct ib_device *device);
 static void cma_remove_one(struct ib_device *device);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index b5e6a7b..ec356ce 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -326,6 +326,7 @@ ipoib_mcast_sendonly_join_complete(int s
 
/* Clear the busy flag so we try again */
clear_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+   mcast->query = NULL;
}
 
complete(&mcast->done);
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c 
b/drivers/infiniband/ulp/srp/ib_srp.c
index 8257d5a..fd8344c 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -799,13 +799,6 @@ static void srp_process_rsp(struct srp_t
spin_unlock_irqrestore(target->scsi_host->host_lock, flags);
 }
 
-static void srp_reconnect_work(void *target_ptr)
-{
-   struct srp_target_port *target = target_ptr;
-
-   srp_reconnect_target(target);
-}
-
 static void srp_handle_recv(struct srp_target_port *target, struct ib_wc *wc)
 {
struct srp_iu *iu;
@@ -858,7 +851,6 @@ static void srp_completion(struct ib_cq 
 {
struct srp_target_port *target = target_ptr;
struct ib_wc wc;
-   unsigned long flags;
 
ib_req_notify_cq(cq, IB_CQ_NEXT_COMP);
while (ib_poll_cq(cq, 1, &wc) > 0) {
@@ -866,10 +858,6 @@ static void srp_completion(struct ib_cq 
printk(KERN_ERR PFX "failed %s status %d\n",
   wc.wr_id & SRP_OP_RECV ? "receive" : "send",
   wc.status);
-   spin_lock_irqsave(target->scsi_host->host_lock, flags);
-   if (target->state == SRP_TARGET_LIVE)
-   schedule_work(&target->work);
-   spin_unlock_irqrestore(target->scsi_host->host_lock, 
flags);
break;
}
 
@@ -1705,8 +1693,6 @@ static ssize_t srp_create_target(struct 
target->scsi_host  = target_host;
target->srp_host   = host;
 
-   INIT_WORK(&target->work, srp_reconnect_work, target);
-
INIT_LIST_HEAD(&target->free_reqs);
INIT_LIST_HEAD(&target->req_queue);
for (i = 0; i < SRP_SQ_SIZE; ++i) {

___
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

Re: [openib-general] [PATCH] ipoib sendonly join

[Roland Dreier]

Thanks, applied

___
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

Re: [openib-general] [PATCH] RDMA/cma: document error flow of rdma_accept

[Roland Dreier]

Sean> Sorry about that.  I was assuming that you could use Or's
Sean> original patch directly.

Then I have to track down the original email which isn't always easy
either.  Anyway don't take it personally, I just created that 
block for standard use now -- you'll probably see it again in other
threads ;)

 - R.

___
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

Re: [openib-general] [PATCH] RDMA/cma: document error flow of rdma_accept

[Sean Hefty]

>I merge > 100 patches every kernel release.  If I have to spend an
>extra 5 minutes creating a patch or pulling it out of svn, then I end
>up burning an extra day of stupid work.  If 20+ people who contribute
>patches sent me clean patches, then everyone will be happier because
>I'll be able to merge things quicker and focus on productive work.

Sorry about that.  I was assuming that you could use Or's original patch
directly.

- Sean

___
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

Re: [openib-general] [PATCH] RDMA/cma: document error flow of rdma_accept

[Roland Dreier]

 > Committed to svn 9461.  Roland, can you also pull into 2.6.19?

Done.


I merge > 100 patches every kernel release.  If I have to spend an
extra 5 minutes creating a patch or pulling it out of svn, then I end
up burning an extra day of stupid work.  If 20+ people who contribute
patches sent me clean patches, then everyone will be happier because
I'll be able to merge things quicker and focus on productive work.


Thanks,
  Roland

___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Robert Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> I installed RC5 and now it just hangs, 
> 
> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
> 4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
> iters=1 | duplex=0 | cma=0 |
> 4702: Local address:  LID 0x03, QPN 0x000d, PSN 0xf1b711 RKey 0x1101200
> VAddr 0x2a95dc8480
> 4702: Remote address: LID 0x04, QPN 0x000d, PSN 0xe62247, RKey 0x1101200
> VAddr 0x2a95c7c480
> hangs here and have to cntrl-c the test.
> 
> 
> Intel MPI also fails with, 
> # Barrier
> [1][rdma_iba.c:260] Intel MPI fatal error: DTO operation completed with
> error. status=0x8. cookie=0x514ee0
> rank 1 in job 4  rkl-13_32779   caused collective abort of all ranks
>   exit status of rank 1: killed by signal 9 

OK - thanks for the report - I'll look into it.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iQEVAwUBRQm6fvzvnpzTd9fxAQKmiggAhKyznnhzO3ndlYYJx58cSX8XK/R5WNz0
CVhrKxVtjhq+cYaP6HAC9HmwuhMm18vlHGmw8fvoiwrhYP1h7dxaVgiAt9dX2rRz
svPd4rZnfIu+L9oZYmy7XBkfawwQR30IZPSUbfQDU1ag2r44HsnyZ6VpKucuHLfL
jUFxryC2lmwAU6GhuTKJ8k7XEEQBL3UoczPfL/PTwpFVYvM8CjMgLjwhIfqH++Hv
khciAfsl8HgK5Hd6jj1WCOzMyZmL7GBGrpTsia/hgUGOHkpmEC9wy3dSDZeIqCbI
4cs961Y2TIuciNraaLPbF4mhFFgaLJe4nzxSeTLfcbfxXraSqKbn9Q==
=pWln
-END PGP SIGNATURE-

___
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

Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready

[Woodruff, Robert J]

Robert Walsh wrote, 
> 
> [EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
> 4730: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
> iters=1 | duplex=0 | cma=0 |
> 4730: Local address:  LID 0x03, QPN 0x001d, PSN 0x9e070c RKey
0x2302400
> VAddr 0x2a95dd3480
> 4730: Remote address: LID 0x04, QPN 0x001e, PSN 0x2bd6ba, RKey
0x2402500
> VAddr 0x2a95c85480
> 4730:main: Completion with error at client:
> 4730:main: Failed status 9: wr_id 3
> 4730:main: scnt=7584, ccnt=6584
> [EMAIL PROTECTED] bin]$  

>Hi Woody,
Robert Walsh wrote, 
>When RC4 is available, there should be a patch in there that will fix
>this.  Can you let us know if you continue to see problems?

>Regards,
> Robert.

I installed RC5 and now it just hangs, 

[EMAIL PROTECTED] bin]$ ./ib_rdma_bw -n 1 -t 1000 -s 200 rkl-12
4702: | port=18515 | ib_port=1 | size=200 | tx_depth=1000 |
iters=1 | duplex=0 | cma=0 |
4702: Local address:  LID 0x03, QPN 0x000d, PSN 0xf1b711 RKey 0x1101200
VAddr 0x2a95dc8480
4702: Remote address: LID 0x04, QPN 0x000d, PSN 0xe62247, RKey 0x1101200
VAddr 0x2a95c7c480
hangs here and have to cntrl-c the test.


Intel MPI also fails with, 
# Barrier
[1][rdma_iba.c:260] Intel MPI fatal error: DTO operation completed with
error. status=0x8. cookie=0x514ee0
rank 1 in job 4  rkl-13_32779   caused collective abort of all ranks
  exit status of rank 1: killed by signal 9 

woody

___
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

Re: [openib-general] How to support IOMMUs for ipath driver

[Ralph Campbell]

On Thu, 2006-09-14 at 13:51 +0300, Or Gerlitz wrote:
> Ralph Campbell wrote:
> > +static inline dma_addr_t ib_dma_map_sg(struct ib_device *dev,
> > +  struct scatterlist *sg, int nents,
> > +  enum dma_data_direction direction)
> > +{
> > +   return dev->map_sg ?
> > +   dev->map_sg(dev, sg, nents, direction) :
> > +   dma_map_sg(dev->dma_device, sg, nents, direction);
> > +}
> 
> As SG dma mapping happens in place and you don't want to change struct 
> scatterlist for every arch, i think you would need to keep some mapping 
> (hash) from each struct scatterlist to its ipath buddy...
> 
> Also you would need to implement the sg_dma_address() and sg_dma_len() 
> macros used by ULP code when page/s is/are to be input-ed for the IB 
> verbs layer eg to get an SG FMR-ed or send/recv from/into a page and use 
> queries into the ipath scatterlist buddy.
> 
> Or.

Here is my thinking so far:

The driver is passed an LKEY/RKEY plus an address.
For ib_get_dma_mr(), the address is currently from
dma_map_single(), dma_map_page(), or dma_map_sg().
With the ib_dma_*() routines, I can intercept these calls
and return something instead of a bus or IOMMU address.
I would like to return a kernel virtual address since that
is the simplest and is what I ultimately need. This is
trivial for dma_map_single() and trivial for low memory
pages for dma_map_page().

I think I can safely just return error for architectures
with high memory pages since the driver really only works
on 64-bit systems (for a variety of reasons which I won't
go into) and those systems don't have high memory.

If I did have to support high memory pages, I think the
DMA address would have to be the address of some kmalloc'ed
structure containing the page pointer and offset (or an
index into a table of such data structures).
I wouldn't want to make ib_dma_map_single() have to use that
but then I would need a way to distingush addresses
returned from ib_dma_map_single() and dma_map_page()/dma_map_sg().

ib_dma_map_sg() is a bit more complex.
The struct scatterlist is defined in the architecture specific headers.
The sg_dma_address() and sg_dma_len() macros are the exported
interface for accessing the DMA address and length.
I would like to minimize the impact to architecture specific code.
Given these constraints, I think the best thing to do is
add ib_sg_dma_address() and ib_sg_dma_len() functions which should
be used instead of sg_dma_address() and sg_dma_len().
Struct scatterlist has to contain at least page, offset, and length
since the SCSI code relies on those.
ib_sg_dma_address would return the page_address() of sg->page
but wouldn't be able to rely on other fields which might be in
the struct scatterlist.
Again, if high page support is needed, ib_sg_dma_address() would
have to do something trickier like for ib_dma_map_page().



___
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

Re: [openib-general] How to support IOMMUs for ipath driver

[Ralph Campbell]

On Thu, 2006-09-14 at 09:36 +0300, Or Gerlitz wrote:
> Ralph Campbell wrote:
> > On Wed, 2006-09-13 at 12:00 +0300, Or Gerlitz wrote:
> >> Ralph Campbell wrote:
> 
> > Well, the other parts of the kernel might not need a kernel virtual
> > address but the ib_ipath driver still does.
> 
> So you agree there is a need to kmap/kunamp pages which the user wants 
> to  use with IB and are not mapped into the kernel virt address space?

Yes, I agree for systems which have high memory pages.

> > I don't understand what you are talking about. There is an IB
> > wire protocol for RDMA, SEND, etc. That doesn't change depending
> > on the HCA.
> > The InfiniPath HCA has a ring buffer of receive buffers and all
> > incoming IB packets are DMA'ed into one of these buffers.
> > The ib_ipath software driver examines the packet and
> > copies it to the appropriate address. For a packet received with
> > a RC_RDMA_WRITE_FIRST, the RKEY and IB address are used to convert
> > that into a kernel virtual address and the data is copied.
> > The same happens for RC_SEND_FIRST but the KV address comes from
> > the LKEY and address in the work request posted by ib_post_recv().
> 
> OK, this make sense.
> 
> Lets see if i follow: you say that the Infinipath HCA is RX DMA-able but 
> it does RX DMA to the ipath driver private RX buffers and then the 
> driver copies from these buffers to the user buffer. My guess is that 
> you do that to support both recv and rdma read on this QP since if you 
> would only need to support recv you can have the hca dma-ing to the user 
> posted rx buffer.

You mostly understand. The hardware doesn't have separate receive
queues for each QP. All packets go into a single (or at most 4
currently) receive queues and the driver figures out which QP,
RDMA memory region, etc. to copy them to.



___
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

Re: [openib-general] IB for FC5/x86_64

[Michael S. Tsirkin]

Quoting r. Greg Allen <[EMAIL PROTECTED]>:
> Subject: IB for FC5/x86_64
> 
> Is there a set of RPMs or SRPMs for FC5/x86_64? Even better, a yum 
> server with them? I've tried generating them from the svn tree, but I 
> keep getting hung up.
> 
> I love the way it works in RHEL4, but the SATA controller in my new 
> box is currently unsupported in RHEL4.
> 
> Thanks,
> -Greg

Try OFED 1.1 RC.
https://openib.org/svn/gen2/branches/1.1/ofed/releases/


-- 
MST

___
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

[openib-general] IB for FC5/x86_64

[Greg Allen]

Is there a set of RPMs or SRPMs for FC5/x86_64? Even better, a yum 
server with them? I've tried generating them from the svn tree, but I 
keep getting hung up.

I love the way it works in RHEL4, but the SATA controller in my new 
box is currently unsupported in RHEL4.

Thanks,
-Greg
-- 
  Gregory E. Allen, MSEE Engineering Scientist
  Applied Research Laboratories: The University of Texas at Austin
  Please help find my missing daughter: http://FindSabrina.org/

___
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

[openib-general] OFED-1.1-RC5 is ready

[vlad]

Hi,

OFED-1.1-rc5 is available on
https://openib.org/svn/gen2/branches/1.1/ofed/releases/
File: OFED-1.1-rc5.tgz
Please report any issues in bugzilla http://openib.org/bugzilla/


Release details:

Build_id:

OFED-1.1-rc5

openib-1.1 (REV=9485)
# User space
https://openib.org/svn/gen2/branches/1.1/src/userspace
Git: git://www.mellanox.co.il/~git/infinibandref: refs/heads/ofed_1_1
commit 18c1cb87c4b16f1a1577807077bbdcba3f446f09

# MPI
mpi_osu-0.9.7-mlx2.2.0.tgz
openmpi-1.1.1-1.src.rpm
mpitests-2.0-0.src.rpm

OS support:
===
Novell:
 - SLES 9.0 SP3
 - SLES10
Redhat:
 - Redhat EL4 up3

 - Redhat EL4 up4
kernel.org:
 - Kernel 2.6.17


Bug fixes from OFED-1.1-rc4:
==
1. ISER compilation fixed on SLES10
2. Fixed build on SLES9 PPC64
3. Updated libehca
4. OpenSM fixes
5. Added tavor_quirk option to rdma_cm module (disabled by default): Tavor
performance quirk: limit MTU to 1K if > 0 (int)

Known issues:
=
libipathverbs compilation fails on SLES10 (Bug:204)


OFED-1.1-rc6 (hopefully the last one) planned to be released on Monday or
Tuesday.


Regards,
Vladimir


> Hi,
>
> The plan is to issue OFED RC5 on Thursday 9/14 and final release next
> week. I am aware of the  following issues:
>
>
> 1) Compilation on SLES9 on PPC - Jack Morgenstein
> 2) Huge pages on PPC  - Eli Cohen
> 3) libipathverbs: - Qlogic
> a) libipathverbs ABI issue
> b) libipathverbs build on SLES10
> 4) SDP performance on Tavor   - Michael Tsirkin
> 5) iSER issue on SLES10   - Voltaire
>
>
> In order to meet tomorrow's RC5 release all owners please send your
> patches by end of today.
>
>
> Regards,
>
> Aviram
>
> ___
> openfabrics-ewg mailing list
> [EMAIL PROTECTED]
> http://openib.org/mailman/listinfo/openfabrics-ewg
>



___
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

[openib-general] [PATCH v2] ib_sa: add generic RMPP query interface

[Sean Hefty]

Patch updated to svn tip, which includes SA registration.

The following patch adds a generic interface to send MADs to the SA.
The primary motivation of adding these calls is to expand the SA query
interface to include RMPP responses for users wanting more than a
single attribute returned from a query (e.g. multipath record queries),
but it also simplifies a userspace interface.

The implementation of existing SA query routines were layered on top
of the generic query interface.

Signed-off-by: Sean Hefty 
---
Index: include/rdma/ib_sa.h
===
--- include/rdma/ib_sa.h(revision 9490)
+++ include/rdma/ib_sa.h(working copy)
@@ -82,6 +82,32 @@ enum {
IB_SA_ATTR_INFORM_INFO_REC   = 0xf3
 };
 
+/* Length of SA attributes on the wire */
+enum {
+   IB_SA_ATTR_CLASS_PORTINFO_LEN   = 72,
+   IB_SA_ATTR_NOTICE_LEN   = 80,
+   IB_SA_ATTR_INFORM_INFO_LEN  = 36,
+   IB_SA_ATTR_NODE_REC_LEN = 108,
+   IB_SA_ATTR_PORT_INFO_REC_LEN= 58,
+   IB_SA_ATTR_SL2VL_REC_LEN= 16,
+   IB_SA_ATTR_SWITCH_REC_LEN   = 21,
+   IB_SA_ATTR_LINEAR_FDB_REC_LEN   = 72,
+   IB_SA_ATTR_RANDOM_FDB_REC_LEN   = 72,
+   IB_SA_ATTR_MCAST_FDB_REC_LEN= 72,
+   IB_SA_ATTR_SM_INFO_REC_LEN  = 25,
+   IB_SA_ATTR_LINK_REC_LEN = 6,
+   IB_SA_ATTR_GUID_INFO_REC_LEN= 72,
+   IB_SA_ATTR_SERVICE_REC_LEN  = 176,
+   IB_SA_ATTR_PARTITION_REC_LEN= 72,
+   IB_SA_ATTR_PATH_REC_LEN = 64,
+   IB_SA_ATTR_VL_ARB_REC_LEN   = 72,
+   IB_SA_ATTR_MC_MEMBER_REC_LEN= 52,
+   IB_SA_ATTR_TRACE_REC_LEN= 46,
+   IB_SA_ATTR_MULTI_PATH_REC_LEN   = 56,
+   IB_SA_ATTR_SERVICE_ASSOC_REC_LEN= 80,
+   IB_SA_ATTR_INFORM_INFO_REC_LEN  = 60
+};
+
 enum ib_sa_selector {
IB_SA_GTE  = 0,
IB_SA_LTE  = 1,
@@ -270,10 +296,83 @@ void ib_sa_register_client(struct ib_sa_
  */
 void ib_sa_unregister_client(struct ib_sa_client *client);
 
+struct ib_sa_iter;
+
+/**
+ * ib_sa_iter_create - Create an iterator that may be used to walk through
+ *   a list of returned SA records.
+ * @mad_recv_wc: A received response from the SA.
+ *
+ * This call allocates an iterator that is used to walk through a list of 
+ * SA records.  Users must free the iterator by calling ib_sa_iter_free.
+ */
+struct ib_sa_iter *ib_sa_iter_create(struct ib_mad_recv_wc *mad_recv_wc);
+
+/**
+ * ib_sa_iter_free - Release an iterator.
+ * @iter: The iterator to free.
+ */
+void ib_sa_iter_free(struct ib_sa_iter *iter);
+
+/**
+ * ib_sa_iter_next - Move an iterator to reference the next attribute and
+ *   return the attribute.
+ * @iter: The iterator to move.
+ *
+ * The referenced attribute will be in wire format.  The funtion returns NULL
+ * if there are no more attributes to return.
+ */
+void *ib_sa_iter_next(struct ib_sa_iter *iter);
+
+/**
+ * ib_sa_attr_size - Return the length of an SA attribute on the wire.
+ * @attr_id: Attribute identifier.
+ */
+int ib_sa_attr_size(__be16 attr_id);
+
 struct ib_sa_query;
 
 void ib_sa_cancel_query(int id, struct ib_sa_query *query);
 
+/**
+ * ib_sa_send_mad - Send a MAD to the SA.
+ * @client:SA client
+ * @device:device to send query on
+ * @port_num: port number to send query on
+ * @method:MAD method to use in the send.
+ * @attr:Reference to attribute in wire format to send in MAD.
+ * @attr_id:Attribute type identifier.
+ * @comp_mask:component mask to send in MAD
+ * @timeout_ms:time to wait for response, if one is expected
+ * @retries:number of times to retry request
+ * @gfp_mask:GFP mask to use for internal allocations
+ * @callback:function called when query completes, times out or is
+ * canceled
+ * @context:opaque user context passed to callback
+ * @sa_query:query context, used to cancel query
+ *
+ * Send a message to the SA.  If a response is expected (timeout_ms is
+ * non-zero), the callback function will be called when the query completes.
+ * Status is 0 for a successful response, -EINTR if the query
+ * is canceled, -ETIMEDOUT is the query timed out, or -EIO if an error
+ * occurred sending the query.  Mad_recv_wc will reference any returned
+ * response from the SA.  It is the responsibility of the caller to free
+ * mad_recv_wc by call ib_free_recv_mad() if it is non-NULL.
+ *
+ * If the return value of ib_sa_send_mad() is negative, it is an
+ * error code.  Otherwise it is a query ID that can be used to cancel
+ * the query.
+ */
+int ib_sa_send_mad(struct ib_sa_client *client,
+  struct ib_device *device, u8 port_num,
+  int method, void *attr, __be16 attr_id,
+  ib_sa_comp_mask comp_mask,
+  int timeout_ms, int retries, gfp_t gfp_mask,
+  void (*callback)(int status,
+   struct ib_mad_recv_wc *mad_recv_wc,
+   void *context),
+   

[openib-general] [PATCH] ipoib sendonly join

[Eli cohen]

When sendonly join fails mcast->query must be set to NULL in
order that succeesive joins will be attempted for the group.

Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: openib-1.1/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- openib-1.1.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c  
2006-09-12 14:28:33.0 +0300
+++ openib-1.1/drivers/infiniband/ulp/ipoib/ipoib_multicast.c   2006-09-14 
17:17:12.0 +0300
@@ -326,6 +326,7 @@
 
/* Clear the busy flag so we try again */
clear_bit(IPOIB_MCAST_FLAG_BUSY, &mcast->flags);
+   mcast->query = NULL;
}
 
complete(&mcast->done);



___
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

[openib-general] ipoib send only failure

[Eli cohen]

Hi,
when running a test I encountered the following scenario:
the test sends to multicast address
ipoib issues send only joins which fails.
successive joins to this group will not be attempted since the query
field of the mcast object holds the old pointer.




___
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

Re: [openib-general] [PATCH] IB/Kconfig: add help text and change CMA config name

[Sean Hefty]

Or Gerlitz wrote:
> change INFINIBAND_ADDR_TRANS to INFINIBAND_RDMA_CM and add help text
> clarifying what the thing does. Adding the help text also has the side
> effect of the cma config being visible when one does make menuconfig
> 
> Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>

Acked-by: Sean Hefty <[EMAIL PROTECTED]>

Were you wanting this 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

Re: [openib-general] [PATCH] IB/iser: fix iSER description and selections in Kconfig

[Roland Dreier]

Wouldn't it better just to depend on INET the way ISCSI_TCP does?
'select' is more fragile and harder to maintain than 'depends' since
you always have to make sure you select the full dependency tree of
every option you really need.

 - R.

___
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

Re: [openib-general] [PATCH] IB/Kconfig: add help text and change CMA config name

[Roland Dreier]

Or> change INFINIBAND_ADDR_TRANS to INFINIBAND_RDMA_CM and add
Or> help text clarifying what the thing does. Adding the help text
Or> also has the side effect of the cma config being visible when
Or> one does make menuconfig

Why do we want to make this config option visible?  Isn't it better
for it to just take the right value automatically?

 - R.

___
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

Re: [openib-general] Different byte order between gen1 CM and gen2 CM ->RE: How to connect gen2 CM to gen1 IBGD CM?

[Sean Hefty]

Bub Thomas wrote:
> Do you know rany other Verbs or CM parameter that does have a different 
> byte order between gen1 and gen2?

I'm not really familiar with the gen1 code.

> P.S.: Maybe someone should put a big “Warning” sign somewhere so that 
> others don’t stumple into that pit again. ;-)

The byte ordering in the kernel APIs are fairly clear about this, but that 
documentation didn't carry up to userspace everywhere.  I will update the 
userspace documentation, but it may take me a few weeks to get to this.

- Sean

___
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

[openib-general] Different byte order between gen1 CM and gen2 CM ->RE: How to connect gen2 CM to gen1 IBGD CM?

[Bub Thomas]

Title: Different byte order between gen1 CM and gen2 CM ->RE: How to connect gen2 CM to gen1 IBGD CM?






Sean,

I should have checked this earlier after you told me last time that the LID is taken in network order by the gen2 CM instead of host order in gen1.

This time it was the service_id I stumbeled over.

After putting my service_id into network order I could at least get a REQ_RECEIVED.

The rest must be fine tuning from here onwards.

Do you know rany other Verbs or CM parameter that does have a different byte order between gen1 and gen2?

Thanks

Thomas

P.S.: Maybe someone should put a big “Warning” sign somewhere so that others don’t stumple into that pit again. ;-)



_
From: Bub Thomas
Sent: Wednesday, September 13, 2006 4:11 PM
To: 'Sean Hefty'; '[EMAIL PROTECTED]'
Cc: openib-general@openib.org
Subject: How to connect gen2 CM to gen1 IBGD CM?

Sean,

with your patience, the cmpost.c example and the OFED 1.1-rc4 on all machines I finally got a gen2 connection under SLES10 even with a 32-Bit executable on a x86_64 machine. Cool!

Now the last part on my journey is standing out.

It’s a gen2 client connecting to a gen1 IBGD server.

I have to do this since my gen1 server is running a 2.4 Montavista RT Linux on a PowerPC that I can’t upgrade to gen2. L

BTW.: Our application is a high speed film image transfer in the film postproduction industry leveraging the benefits of the high speed IB RDMA transport. 

While I have gen1 to gen1 and gen2 to gen2 running the only thing that is missing is the gen2 connecting to gen1.

Just tried this with my test-executables but I did not get anything to the gen1 server. The gen1 userspace application does not even receive the IB_CM_REQ.

So since your cmpost example did help me a lot on gen2 the question is:

Do you have a cmpost for gen1 IBGD I can use to connect from gen2 to gen1?

Or is there any other trick to play here?

Thanks in advance for your assistance

Thomas


Thomas Bub
Grass Valley Germany GmbH
Brunnenweg 9
64331 Weiterstadt, Germany
Tel: +49 6150 104 147
Fax: +49 6150 104 656
Email: [EMAIL PROTECTED]
www.GrassValley.com





___
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

[openib-general] Fwd: IPoIB Multicast

[Michael S. Tsirkin]

Subject: IPoIB Multicast
Date: Thu, 14 Sep 2006 17:08:55 +0300
From: "Eitan Zahavi" <[EMAIL PROTECTED]>
> 
> Quoting the   
> 
> A node joining an IP multicast group must first construct a MGID
> according to the rule described in section 4 above. Once the correct
> MGID is calculated, the node must call the SA of the outbound link
> to attempt a "FullMember" join of the IB multicast group
> corresponding to the MGID. If the IB multicast group doesn't already
> exist, one must be created first with the IPoIB link MTU.  The MGID
> MUST use the same P_Key, Q_Key, SL, MTU and HopLimit as those used
> in the broadcast-GID. For the rest of attributes too, the values
> used in the broadcast-GID SHOULD be used.

Hmm, IPoIB does not seem to copy anything except the pkey.
Looks like a compliance issue.

Specifically, I'm not sure what "other attributes" are, but I think
this should include the static rate. Right?

-- 
MST

___
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

Re: [openib-general] [PATCH] OpenSM: Change default temp directory location for non Windows platforms

[Hal Rosenstock]

Hi Eitan,

On Thu, 2006-09-14 at 09:39, Eitan Zahavi wrote:
> Hi Hal,
> Looks simple enough to get into the OFED 1.1
> I assume you are going to commit it into the branch?

Done (r9484).

-- Hal

> 
> EZ
> 
> Hal Rosenstock wrote:
> 
> >OpenSM: Change default temp directory location for non Windows platforms
> >
> >This patch is intended for both trunk and 1.1.
> >
> >Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> >
> >Index: ../osm/include/opensm/osm_base.h
> >===
> >--- ../osm/include/opensm/osm_base.h (revision 9347)
> >+++ ../osm/include/opensm/osm_base.h (working copy)
> >@@ -176,16 +176,15 @@ BEGIN_C_DECLS
> > *   OSM_DEFAULT_TMP_DIR
> > *
> > * DESCRIPTION
> >-*   Specifies the default temporary directory for the log file, subnet.lst
> >-*  and the other log files (with the exception of osm.log for Linux being 
> >-*  in /var/log).
> >+*   Specifies the default temporary directory for the log file,
> >+*  subnet.lst, and other log files.
> > *
> > * SYNOPSIS
> > */
> > #ifdef __WIN__
> > #define OSM_DEFAULT_TMP_DIR GetOsmTempPath()
> > #else
> >-#define OSM_DEFAULT_TMP_DIR "/tmp/"
> >+#define OSM_DEFAULT_TMP_DIR "/var/log/"
> > #endif
> > /***/
> > 
> >
> >
> >
> >
> >___
> >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
> >  
> >
> 


___
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

Re: [openib-general] [PATCH] OpenSM: Change default temp directory location for non Windows platforms

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: [PATCH] OpenSM: Change default temp directory location for non 
> Windows platforms
> 
> OpenSM: Change default temp directory location for non Windows platforms
> 
> This patch is intended for both trunk and 1.1.

Could you please delay the commit till tomorrow so that we can get RC5 out?
This still can get in before final.

-- 
MST

___
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

Re: [openib-general] [PATCH] OpenSM: Change default temp directory location for non Windows platforms

[Eitan Zahavi]

Hi Hal,
Looks simple enough to get into the OFED 1.1
I assume you are going to commit it into the branch?

EZ

Hal Rosenstock wrote:

>OpenSM: Change default temp directory location for non Windows platforms
>
>This patch is intended for both trunk and 1.1.
>
>Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
>
>Index: ../osm/include/opensm/osm_base.h
>===
>--- ../osm/include/opensm/osm_base.h   (revision 9347)
>+++ ../osm/include/opensm/osm_base.h   (working copy)
>@@ -176,16 +176,15 @@ BEGIN_C_DECLS
> * OSM_DEFAULT_TMP_DIR
> *
> * DESCRIPTION
>-* Specifies the default temporary directory for the log file, subnet.lst
>-*  and the other log files (with the exception of osm.log for Linux being 
>-*  in /var/log).
>+* Specifies the default temporary directory for the log file,
>+*  subnet.lst, and other log files.
> *
> * SYNOPSIS
> */
> #ifdef __WIN__
> #define OSM_DEFAULT_TMP_DIR GetOsmTempPath()
> #else
>-#define OSM_DEFAULT_TMP_DIR "/tmp/"
>+#define OSM_DEFAULT_TMP_DIR "/var/log/"
> #endif
> /***/
> 
>
>
>
>
>___
>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
>  
>


___
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

[openib-general] [PATCH] OpenSM: Change default temp directory location for non Windows platforms

[Hal Rosenstock]

OpenSM: Change default temp directory location for non Windows platforms

This patch is intended for both trunk and 1.1.

Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

Index: ../osm/include/opensm/osm_base.h
===
--- ../osm/include/opensm/osm_base.h(revision 9347)
+++ ../osm/include/opensm/osm_base.h(working copy)
@@ -176,16 +176,15 @@ BEGIN_C_DECLS
 *  OSM_DEFAULT_TMP_DIR
 *
 * DESCRIPTION
-*  Specifies the default temporary directory for the log file, subnet.lst
-*  and the other log files (with the exception of osm.log for Linux being 
-*  in /var/log).
+*  Specifies the default temporary directory for the log file,
+*  subnet.lst, and other log files.
 *
 * SYNOPSIS
 */
 #ifdef __WIN__
 #define OSM_DEFAULT_TMP_DIR GetOsmTempPath()
 #else
-#define OSM_DEFAULT_TMP_DIR "/tmp/"
+#define OSM_DEFAULT_TMP_DIR "/var/log/"
 #endif
 /***/
 




___
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

Re: [openib-general] OFED can't compile against sa.h under SLES10 x86_64

[Bub Thomas]

Jack et all,
I have to apologize my -I. include path pointed to OFED-1.0.1 includes
where the ibv_sa_path_record was not defined yet.
Doing it right it works
Thanks to all for the sudden support 
Thomas (humbling backwards) ;-)


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:openib-general-
> [EMAIL PROTECTED] On Behalf Of Jack Morgenstein
> Sent: Thursday, September 14, 2006 1:12 PM
> To: Bub Thomas
> Cc: openib-general@openib.org
> Subject: [openib-general] OFED can't compile against sa.h under SLES10
> x86_64
> 
> I was unable to reproduce the problem you describe, under SLES10
x86_64.
> Here, your cmpost.c file compiled and linked without any problems.
> I used a slightly different gcc command line (given below).
> 
> I took the cmpost.c file you provided, placed it under
> /usr/local/ofed/src/openib-1.1/src/userspace/libibcm/examples
> (under an OFED 1.1-rc5 prerelease candidate installation).
> I then did the following:
> 
>  cd libibcm/examples
> 
>  gcc -ggdb  -Wall -O0 -I/usr/local/ofed/include  -D__x86_64__
>   /usr/local/ofed/lib64/libibcommon.so
> /usr/local/ofed/lib64/librdmacm.so
>   /usr/local/ofed/lib64/libibcm.so  -o cmpost cmpost.c
> 
> (the above gcc command is broken up into several lines for easy
reading)
> 
> The compilation was successful. I did not experience any compilation
or
> linkage problems.
> I was able to run the resulting "cmpost" executable file.
> 
> gcc version: gcc (GCC) 4.1.0 (SUSE Linux)
> Linux distribution: (from file /etc/SuSE-release):
> SUSE Linux Enterprise Server 10 (x86_64)
> VERSION = 10
> 
> Kernel version (uname -a):
> Linux 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64
> x86_64 x86_64 GNU/Linux
> 
> I then retried everything using OFED 1.1 RC4, and also succeeded in
> compiling and running cmpost.c.
> 
> The following is the list of OFED packages that I installed for the
above
> experiment:
> ib_ipoib
> ib_mthca
> ib_verbs
> kernel-ib
> kernel-ib-devel
> libibcm
> libibcm-devel
> libibcommon
> libibcommon-devel
> libibmad
> libibmad-devel
> libibumad
> libibumad-devel
> libibverbs
> libibverbs-devel
> libibverbs-utils
> libmthca
> libmthca-devel
> librdmacm
> librdmacm-devel
> librdmacm-utils
> ofed-scripts
> 
> - Jack
> 
> ___
> 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



___
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

Re: [openib-general] [PATCH] IB/ipoib: use appropriate path selector

[Hal Rosenstock]

On Thu, 2006-09-14 at 07:14, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > 
> > On Thu, 2006-09-14 at 00:46, Michael S. Tsirkin wrote:
> > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > > > 
> > > > On Wed, 2006-09-13 at 18:08, Michael S. Tsirkin wrote:
> > > > > Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > > > > > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > > > > > 
> > > > > > Michael> IPoIB in linux needs 2K MTU. Therefore it must set mtu
> > > > > > Michael> selector in path record query accordingly.
> > > > > > 
> > > > > > Umm -- why does it need a 2K MTU?  As far as I know it should work
> > > > > > fine with any MTU, assuming the SA sets the MTU of the broadcast
> > > > > > multicast group correctly.
> > > > > 
> > > > > Hmm, you are right, it is just that existing implementations all
> > > > > set that to 2K.
> > > > 
> > > > By default yes. It can be configured.
> > > > 
> > > > > But there is a silent assumption that MTU of any path is >= broadcast
> > > > > multicast group MTU, and this is what I want to fix.
> > > > 
> > > > The spec says:
> > > > "The value (for IB MTU) assigned to the broadcast-GID must not be
> > > > greater than any physical link MTU spanned by the IPoIB subnet".
> > > > so if the broadcast group is improperly setup not to follow this, there
> > > > will be other issues.
> > > 
> > > Correct. IPoIB uses broadcast group MTU to get the value reported to
> > > Linux. If some link has a lower MTU IPoIB can not use it.
> > > 
> > > > It doesn't need to be included in the PR request.
> > > 
> > > I disagree here. If you do not set selector, SA is free to return
> > > a path with lower MTU even though physical link allows higher MTU.
> > > Does it say otherwise somewhere?
> > 
> > No but isn't this relying on using PRs in a certain way by IPoIB
> > implementations (and any other UD application) v. connected apps ?
> 
> Not really.
> 
> Tavor is faster with 1K MTU than with 2K MTU - it does not matter connected or
> not. So, for me, it makes sense for SM to choose 1K if Tavor is involved,
> unless application requested otherwise.
> 
> If an application (again, no matter connected or UD) needs a specific MTU it
> should use mtu selector in path query. If it does not, SM is free to choose 
> any
> MTU supported by link, for best performance. If one end is Tavor, this 
> happens to
> be 1K and not the maximum MTU.
> 
> So what we have here is IPoIB bug - it requires that path mtu >= bcast group
> mtu, but does not pass this information in query. This only happens to work
> if SM always selects max link MTU for each path query.

> Makes sense?

Understood. As I said in a previous email, if it happens that the path
MTU < broadcast group MTU, I think there would be join issues for some
nodes out there.

-- Hal




___
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

Re: [openib-general] [PATCH] IB/ipoib: use appropriate path selector

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> 
> On Thu, 2006-09-14 at 00:46, Michael S. Tsirkin wrote:
> > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > > 
> > > On Wed, 2006-09-13 at 18:08, Michael S. Tsirkin wrote:
> > > > Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > > > > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > > > > 
> > > > > Michael> IPoIB in linux needs 2K MTU. Therefore it must set mtu
> > > > > Michael> selector in path record query accordingly.
> > > > > 
> > > > > Umm -- why does it need a 2K MTU?  As far as I know it should work
> > > > > fine with any MTU, assuming the SA sets the MTU of the broadcast
> > > > > multicast group correctly.
> > > > 
> > > > Hmm, you are right, it is just that existing implementations all
> > > > set that to 2K.
> > > 
> > > By default yes. It can be configured.
> > > 
> > > > But there is a silent assumption that MTU of any path is >= broadcast
> > > > multicast group MTU, and this is what I want to fix.
> > > 
> > > The spec says:
> > > "The value (for IB MTU) assigned to the broadcast-GID must not be
> > > greater than any physical link MTU spanned by the IPoIB subnet".
> > > so if the broadcast group is improperly setup not to follow this, there
> > > will be other issues.
> > 
> > Correct. IPoIB uses broadcast group MTU to get the value reported to
> > Linux. If some link has a lower MTU IPoIB can not use it.
> > 
> > > It doesn't need to be included in the PR request.
> > 
> > I disagree here. If you do not set selector, SA is free to return
> > a path with lower MTU even though physical link allows higher MTU.
> > Does it say otherwise somewhere?
> 
> No but isn't this relying on using PRs in a certain way by IPoIB
> implementations (and any other UD application) v. connected apps ?

Not really.

Tavor is faster with 1K MTU than with 2K MTU - it does not matter connected or
not. So, for me, it makes sense for SM to choose 1K if Tavor is involved,
unless application requested otherwise.

If an application (again, no matter connected or UD) needs a specific MTU it
should use mtu selector in path query. If it does not, SM is free to choose any
MTU supported by link, for best performance. If one end is Tavor, this happens 
to
be 1K and not the maximum MTU.

So what we have here is IPoIB bug - it requires that path mtu >= bcast group
mtu, but does not pass this information in query. This only happens to work
if SM always selects max link MTU for each path query.

Makes sense?

-- 
MST

___
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

[openib-general] OFED can't compile against sa.h under SLES10 x86_64

[Jack Morgenstein]

I was unable to reproduce the problem you describe, under SLES10 x86_64.
Here, your cmpost.c file compiled and linked without any problems.
I used a slightly different gcc command line (given below).

I took the cmpost.c file you provided, placed it under 
/usr/local/ofed/src/openib-1.1/src/userspace/libibcm/examples 
(under an OFED 1.1-rc5 prerelease candidate installation).
I then did the following:

 cd libibcm/examples

 gcc -ggdb  -Wall -O0 -I/usr/local/ofed/include  -D__x86_64__  
  /usr/local/ofed/lib64/libibcommon.so /usr/local/ofed/lib64/librdmacm.so 
  /usr/local/ofed/lib64/libibcm.so  -o cmpost cmpost.c

(the above gcc command is broken up into several lines for easy reading)

The compilation was successful. I did not experience any compilation or linkage 
problems.
I was able to run the resulting "cmpost" executable file.

gcc version: gcc (GCC) 4.1.0 (SUSE Linux)
Linux distribution: (from file /etc/SuSE-release):
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10

Kernel version (uname -a):
Linux 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64 x86_64 
x86_64 GNU/Linux

I then retried everything using OFED 1.1 RC4, and also succeeded in compiling 
and running cmpost.c.

The following is the list of OFED packages that I installed for the above 
experiment:
ib_ipoib
ib_mthca
ib_verbs
kernel-ib
kernel-ib-devel
libibcm
libibcm-devel
libibcommon
libibcommon-devel
libibmad
libibmad-devel
libibumad
libibumad-devel
libibverbs
libibverbs-devel
libibverbs-utils
libmthca
libmthca-devel
librdmacm
librdmacm-devel
librdmacm-utils
ofed-scripts

- Jack

___
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

Re: [openib-general] [PATCH] IB/ipoib: use appropriate path selector

[Hal Rosenstock]

On Thu, 2006-09-14 at 00:46, Michael S. Tsirkin wrote:
> Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > 
> > On Wed, 2006-09-13 at 18:08, Michael S. Tsirkin wrote:
> > > Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> > > > Subject: Re: [PATCH] IB/ipoib: use appropriate path selector
> > > > 
> > > > Michael> IPoIB in linux needs 2K MTU. Therefore it must set mtu
> > > > Michael> selector in path record query accordingly.
> > > > 
> > > > Umm -- why does it need a 2K MTU?  As far as I know it should work
> > > > fine with any MTU, assuming the SA sets the MTU of the broadcast
> > > > multicast group correctly.
> > > 
> > > Hmm, you are right, it is just that existing implementations all
> > > set that to 2K.
> > 
> > By default yes. It can be configured.
> > 
> > > But there is a silent assumption that MTU of any path is >= broadcast
> > > multicast group MTU, and this is what I want to fix.
> > 
> > The spec says:
> > "The value (for IB MTU) assigned to the broadcast-GID must not be
> > greater than any physical link MTU spanned by the IPoIB subnet".
> > so if the broadcast group is improperly setup not to follow this, there
> > will be other issues.
> 
> Correct. IPoIB uses broadcast group MTU to get the value reported to
> Linux. If some link has a lower MTU IPoIB can not use it.
> 
> > It doesn't need to be included in the PR request.
> 
> I disagree here. If you do not set selector, SA is free to return
> a path with lower MTU even though physical link allows higher MTU.
> Does it say otherwise somewhere?

No but isn't this relying on using PRs in a certain way by IPoIB
implementations (and any other UD application) v. connected apps ?

-- Hal



___
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

Re: [openib-general] How to support IOMMUs for ipath driver

[Or Gerlitz]

Ralph Campbell wrote:
> +static inline dma_addr_t ib_dma_map_sg(struct ib_device *dev,
> +struct scatterlist *sg, int nents,
> +enum dma_data_direction direction)
> +{
> + return dev->map_sg ?
> + dev->map_sg(dev, sg, nents, direction) :
> + dma_map_sg(dev->dma_device, sg, nents, direction);
> +}

As SG dma mapping happens in place and you don't want to change struct 
scatterlist for every arch, i think you would need to keep some mapping 
(hash) from each struct scatterlist to its ipath buddy...

Also you would need to implement the sg_dma_address() and sg_dma_len() 
macros used by ULP code when page/s is/are to be input-ed for the IB 
verbs layer eg to get an SG FMR-ed or send/recv from/into a page and use 
queries into the ipath scatterlist buddy.

Or.


___
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

[openib-general] [PATCH] IB/iser: fix iSER description and selections in Kconfig

[Erez Zilber]

Erez Zilber wrote:
> Roland Dreier wrote:
>   
>> There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
>> file.  ISER only depends on INFINIBAND && SCSI.  However it is easily
>> possible to enable INFINIBAND and SCSI without enabling INET (in fact
>> they can be enabled without NET as in the original config in this thread).
>>
>> iser does select SCSI_ISCSI_ATTRS, but without selecting NET that it
>> depends on, so this alone will result in a broken config.  However
>> nothing will enable INET (which I think you said iser depends on).  So
>> something like the below is required, I think.  Although it would
>> probably be better to make iser depend on INET (as ISCSI_TCP does)
>> rather than selecting NET and INET.
>>
>> Toralf, can you confirm that applying this patch and doing make
>> oldconfig and make with your original config works OK?
>>
>> Thanks,
>>   Roland
>>
>> diff --git a/drivers/infiniband/ulp/iser/Kconfig 
>> b/drivers/infiniband/ulp/iser/Kconfig
>> index fead87d..a122bb4 100644
>> --- a/drivers/infiniband/ulp/iser/Kconfig
>> +++ b/drivers/infiniband/ulp/iser/Kconfig
>> @@ -1,6 +1,8 @@
>>  config INFINIBAND_ISER
>>  tristate "ISCSI RDMA Protocol"
>>  depends on INFINIBAND && SCSI
>> +select NET
>> +select INET
>>  select SCSI_ISCSI_ATTRS
>>  ---help---
>>Support for the ISCSI RDMA Protocol over InfiniBand.  This
>>   
>> 
> Roland,
>
> I think that the patch below covers all cases. It depends on the patch 
> that Or sent this morning for the config entry of the CMA.
>
>
>   
Please ignore the previous message. I didn't format the subject 
correctly. Here it is again:

fix the description of iSER in Kconfig. It is not accurate.
Also, iSER used the CMA and INET. It depends on SCSI_ISCSI_ATTRS
that depends on NET. Selecting NET, INET & INFINIBAND_RDMA_CM
ensures that the config won't break.

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>

---

 drivers/infiniband/ulp/iser/Kconfig |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

3dc4e3bf0716d502a6fd7e62806c4932e8978e6b
diff --git a/drivers/infiniband/ulp/iser/Kconfig 
b/drivers/infiniband/ulp/iser/Kconfig
index fead87d..c251855 100644
--- a/drivers/infiniband/ulp/iser/Kconfig
+++ b/drivers/infiniband/ulp/iser/Kconfig
@@ -1,11 +1,14 @@
 config INFINIBAND_ISER
-   tristate "ISCSI RDMA Protocol"
+   tristate "iSCSI Extensions for RDMA (iSER)"
depends on INFINIBAND && SCSI
+   select NET
+   select INET
+   select INFINIBAND_RDMA_CM
select SCSI_ISCSI_ATTRS
---help---
- Support for the ISCSI RDMA Protocol over InfiniBand.  This
- allows you to access storage devices that speak ISER/ISCSI
+ Support for the iSCSI Extensions for RDMA (iSER) Protocol over 
InfiniBand. This
+ allows you to access storage devices that speak iSCSI over iSER
  over InfiniBand.

  The ISER protocol is defined by IETF.
- See .
+ See 
.
--
1.2.6




___
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

[openib-general] 2 SLES 10 backport directories

[Erez Zilber]

Michael,

I saw that there are 2 SLES 10 backport directories in the svn:

https://openib.org/svn/gen2/branches/backport/sles10/ - this one 
contains patches that we added for SLES 10

https://openib.org/svn/gen2/branches/backport/2.6.16_sles10/ - this one 
was added later by you.

Can we unite them?

Here's my motivation: I want to be able to install SLES 10, replace its 
infiniband dir with infiniband from openib's svn, apply all SLES 10 
patches (from a single directory) and then it should work.

This should help us in future OFED releases.

Thanks
-- 



Erez Zilber | 972-9-971-7689

Software Engineer, Storage Team

Voltaire – _The Grid Backbone_

__

www.voltaire.com 



___
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

[openib-general] fix iSER description and selections in Kconfig

[Erez Zilber]

Roland Dreier wrote:
> There is definitely a bug in the drivers/infiniband/ulp/iser/Kconfig
> file.  ISER only depends on INFINIBAND && SCSI.  However it is easily
> possible to enable INFINIBAND and SCSI without enabling INET (in fact
> they can be enabled without NET as in the original config in this thread).
>
> iser does select SCSI_ISCSI_ATTRS, but without selecting NET that it
> depends on, so this alone will result in a broken config.  However
> nothing will enable INET (which I think you said iser depends on).  So
> something like the below is required, I think.  Although it would
> probably be better to make iser depend on INET (as ISCSI_TCP does)
> rather than selecting NET and INET.
>
> Toralf, can you confirm that applying this patch and doing make
> oldconfig and make with your original config works OK?
>
> Thanks,
>   Roland
>
> diff --git a/drivers/infiniband/ulp/iser/Kconfig 
> b/drivers/infiniband/ulp/iser/Kconfig
> index fead87d..a122bb4 100644
> --- a/drivers/infiniband/ulp/iser/Kconfig
> +++ b/drivers/infiniband/ulp/iser/Kconfig
> @@ -1,6 +1,8 @@
>  config INFINIBAND_ISER
>   tristate "ISCSI RDMA Protocol"
>   depends on INFINIBAND && SCSI
> + select NET
> + select INET
>   select SCSI_ISCSI_ATTRS
>   ---help---
> Support for the ISCSI RDMA Protocol over InfiniBand.  This
>   
Roland,

I think that the patch below covers all cases. It depends on the patch 
that Or sent this morning for the config entry of the CMA.

fix the description of iSER in Kconfig. It is not accurate.
Also, iSER used the CMA and INET. It depends on SCSI_ISCSI_ATTRS
that depends on NET. Selecting NET, INET & INFINIBAND_RDMA_CM
ensures that the config won't break.

Signed-off-by: Erez Zilber <[EMAIL PROTECTED]>

---

 drivers/infiniband/ulp/iser/Kconfig |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

3dc4e3bf0716d502a6fd7e62806c4932e8978e6b
diff --git a/drivers/infiniband/ulp/iser/Kconfig 
b/drivers/infiniband/ulp/iser/Kconfig
index fead87d..c251855 100644
--- a/drivers/infiniband/ulp/iser/Kconfig
+++ b/drivers/infiniband/ulp/iser/Kconfig
@@ -1,11 +1,14 @@
 config INFINIBAND_ISER
-   tristate "ISCSI RDMA Protocol"
+   tristate "iSCSI Extensions for RDMA (iSER)"
depends on INFINIBAND && SCSI
+   select NET
+   select INET
+   select INFINIBAND_RDMA_CM
select SCSI_ISCSI_ATTRS
---help---
- Support for the ISCSI RDMA Protocol over InfiniBand.  This
- allows you to access storage devices that speak ISER/ISCSI
+ Support for the iSCSI Extensions for RDMA (iSER) Protocol over 
InfiniBand. This
+ allows you to access storage devices that speak iSCSI over iSER
  over InfiniBand.

  The ISER protocol is defined by IETF.
- See .
+ See 
.
--
1.2.6



___
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

[openib-general] [PATCH] IB/Kconfig: add help text and change CMA config name

[Or Gerlitz]

change INFINIBAND_ADDR_TRANS to INFINIBAND_RDMA_CM and add help text
clarifying what the thing does. Adding the help text also has the side
effect of the cma config being visible when one does make menuconfig

Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>

diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index 69a53d4..7feea77 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -29,11 +29,16 @@ config INFINIBAND_USER_ACCESS
  libibverbs, libibcm and a hardware driver library from
  .

-config INFINIBAND_ADDR_TRANS
+config INFINIBAND_RDMA_CM
bool
depends on INFINIBAND && INET
default y
-
+   ---help---
+ RDMA transport independent communication management support.
+ This includes handling of IP to RDMA address resolution (eg IB ARP),
+ IB route resolution (eg IB SA Path query) and interaction with the
+ transport communication manager (eg the IB and iWARP CM).
+
 source "drivers/infiniband/hw/mthca/Kconfig"
 source "drivers/infiniband/hw/ipath/Kconfig"

diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index 68e73ec..531b3c4 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -1,4 +1,4 @@
-infiniband-$(CONFIG_INFINIBAND_ADDR_TRANS) := ib_addr.o rdma_cm.o
+infiniband-$(CONFIG_INFINIBAND_RDMA_CM):= ib_addr.o rdma_cm.o

 obj-$(CONFIG_INFINIBAND) +=ib_core.o ib_mad.o ib_sa.o \
ib_cm.o $(infiniband-y)

___
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