date:20070117

Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

2007-01-17 Thread Tziporet Koren

Roland Dreier wrote:
 I believe I have a way to make libibverbs 1.1 binary-compatible with
 applications (but not drivers) built against libibverbs 1.0.  So it
 will probably not be necessary to include libibverbs 1.0.

  - R.

   
This is very good. When will we have this change (since libibverbs is 
very centric I prefer having it sooner than later)

Thanks,
Tziporet


___
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] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

2007-01-17 Thread Tziporet Koren

Or Gerlitz wrote:
 Tziporet Koren wrote:


   
 The bonding package would support: fresh (2.6.20) and some older 
 upstream kernels along with SLES10 and RH4 Ux (x=3 for sure)

   
OK - please send us all the info once its ready
   General changes to the package:
 * Multicast - we wait for Voltaire and Sean to close all technical
   details - should be ready by the end of the week
 

 I have just sent Sean over the list a clarification email, if needed we 
 would be able to help doing the missing patches and i guess in a 
 combined effort this would be ready for the end of --next-- week

   
Thanks - please work with MST  Vlad on integration
 what about the host side QoS code? i did not see an newer RFC nor patch 
 other then the RFC that was sent many months ago.


   
We are going to update our low level driver (mthca) to support it. 
Beside there should be a small change in CMA for this, and its specified 
in the RFC.

Tziporet

___
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] Reminder: OFED 1.2

2007-01-17 Thread Tziporet Koren

Jeff Squyres wrote:
 FWIW, having git's for the MPI implementations was asked for on the  
 call yesterday (by Tziporet, IIRC?).  The rationale, as I understood  
 it, was threefold:

 1. Putting the MPI release in git provides a level of OFED-specific  
 history and version control.  This was explicitly stated on the call  
 yesterday.

 2. MPI's have concrete releases to OFED just like all other ULP's,  
 especially if there is any OFED-specific packaging involved in the  
 MPI's release.  This was not stated on the call, but it makes sense  
 to me.

 3. Putting everything in git makes it nicely uniform for OFED to be  
 assembled.  This was not stated on the call, and I'm sure it's not a  
 requirement, but it is a little nice to be uniform when assembling  
 OFED (my $0.02).

 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior  
 OFED release processes, so putting them in a git seems to parallel  
 that procedure.

 I don't really care one way or another; this was just my  
 understanding of why it was requested.


   
Hi,
Jeff is correct - I requested this from the reasons above.

Tziporet

___
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] [libibverbs/examples] pingpong tests cleanup (resource destroy + ack events + asprintf failure check)

2007-01-17 Thread Dotan Barak

Roland Dreier wrote:
 Looks pretty good, but could you please:

  - split off the asprintf() checks into a separate patch (one idea
per patch).
  - change the code so it keeps a count of cq events and then just
does one ibv_ack_cq_events(cq, num_cq_events) at the end.  If
people are going to use this code as an example, then we should
avoid expensive calls to ibv_ack_cq_events() (which has to do a
pthread_mutex_lock()/unlock() and a pthread_cond_signal()) in the
main data-moving flow.

 thanks...
   
- i wanted to give one patch with all of the fixes, but separate patches 
are fine by me (i will keep that in mind).
- i will change the code according to this tip (and add it to the man 
pages of this verb)

later on i will send the 2 patches.

thanks
Dotan


___
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] [libibverbs/examples] [PATCH] Added checks to memory allocation failure when using asprintf in pingpong tests

2007-01-17 Thread Dotan Barak

Added checks to memory allocation failure when using asprintf in pingpong tests.

Signed-off-by: Dotan Barak [EMAIL PROTECTED]
---

Index: gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/rc_pingpong.c
2007-01-15 17:02:23.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c 
2007-01-16 09:56:52.0 +0200
@@ -139,7 +139,9 @@ static struct pingpong_dest *pp_client_e
int sockfd = -1;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(servername, service, hints, res);
 
if (n  0) {
@@ -205,7 +207,9 @@ static struct pingpong_dest *pp_server_e
int sockfd = -1, connfd;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(NULL, service, hints, res);
 
if (n  0) {
Index: gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/srq_pingpong.c   
2007-01-15 17:02:23.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c
2007-01-16 09:57:25.0 +0200
@@ -150,7 +150,9 @@ static struct pingpong_dest *pp_client_e
int sockfd = -1;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(servername, service, hints, res);
 
if (n  0) {
@@ -229,7 +231,9 @@ static struct pingpong_dest *pp_server_e
int sockfd = -1, connfd;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(NULL, service, hints, res);
 
if (n  0) {
Index: gen2_devel_user/src/userspace/libibverbs/examples/uc_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/uc_pingpong.c
2007-01-15 17:02:23.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/uc_pingpong.c 
2007-01-16 09:57:54.0 +0200
@@ -127,7 +127,9 @@ static struct pingpong_dest *pp_client_e
int sockfd = -1;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(servername, service, hints, res);
 
if (n  0) {
@@ -193,7 +195,9 @@ static struct pingpong_dest *pp_server_e
int sockfd = -1, connfd;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(NULL, service, hints, res);
 
if (n  0) {
Index: gen2_devel_user/src/userspace/libibverbs/examples/ud_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/ud_pingpong.c
2007-01-15 17:02:23.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/ud_pingpong.c 
2007-01-16 09:58:22.0 +0200
@@ -128,7 +128,9 @@ static struct pingpong_dest *pp_client_e
int sockfd = -1;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(servername, service, hints, res);
 
if (n  0) {
@@ -194,7 +196,9 @@ static struct pingpong_dest *pp_server_e
int sockfd = -1, connfd;
struct pingpong_dest *rem_dest = NULL;
 
-   asprintf(service, %d, port);
+   if (asprintf(service, %d, port)  0)
+   return NULL;
+
n = getaddrinfo(NULL, service, hints, res);
 
if (n  0) {



___
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] [libibverbs/examples] [PATCH] Added resource cleaning before end of pingpong tests + ack to CQ events

2007-01-17 Thread Dotan Barak

Added resource cleaning before end of pingpong tests + ack to CQ events.

Signed-off-by: Dotan Barak [EMAIL PROTECTED]
---

Index: gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/rc_pingpong.c
2007-01-17 10:58:02.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c 
2007-01-17 11:09:59.0 +0200
@@ -322,7 +322,7 @@ static struct pingpong_context *pp_init_
 
ctx-mr = ibv_reg_mr(ctx-pd, ctx-buf, size, IBV_ACCESS_LOCAL_WRITE);
if (!ctx-mr) {
-   fprintf(stderr, Couldn't allocate MR\n);
+   fprintf(stderr, Couldn't register MR\n);
return NULL;
}
 
@@ -374,6 +374,46 @@ static struct pingpong_context *pp_init_
return ctx;
 }
 
+int pp_close_ctx(struct pingpong_context *ctx)
+{
+   if (ibv_destroy_qp(ctx-qp)) {
+   fprintf(stderr, Couldn't destroy QP\n);
+   return 1;
+   }
+
+   if (ibv_destroy_cq(ctx-cq)) {
+   fprintf(stderr, Couldn't destroy CQ\n);
+   return 1;
+   }
+
+   if (ibv_dereg_mr(ctx-mr)) {
+   fprintf(stderr, Couldn't deregister MR\n);
+   return 1;
+   }
+
+   if (ibv_dealloc_pd(ctx-pd)) {
+   fprintf(stderr, Couldn't deallocate PD\n);
+   return 1;
+   }
+
+   if (ctx-channel) {
+   if (ibv_destroy_comp_channel(ctx-channel)) {
+   fprintf(stderr, Couldn't destroy completion 
channel\n);
+   return 1;
+   }
+   }
+
+   if (ibv_close_device(ctx-context)) {
+   fprintf(stderr, Couldn't release context\n);
+   return 1;
+   }
+
+   free(ctx-buf);
+   free(ctx);
+
+   return 0;
+}
+
 static int pp_post_recv(struct pingpong_context *ctx, int n)
 {
struct ibv_sge list = {
@@ -451,6 +491,7 @@ int main(int argc, char *argv[])
int  use_event = 0;
int  routs;
int  rcnt, scnt;
+   int  num_of_events = 0;
 
srand48(getpid() * time(NULL));
 
@@ -622,6 +663,8 @@ int main(int argc, char *argv[])
return 1;
}
 
+   ++num_of_events;
+
if (ev_cq != ctx-cq) {
fprintf(stderr, CQ event for unknown CQ %p\n, 
ev_cq);
return 1;
@@ -706,5 +749,13 @@ int main(int argc, char *argv[])
   iters, usec / 100., usec / iters);
}
 
+   ibv_ack_cq_events(ctx-cq, num_of_events);
+
+   if (pp_close_ctx(ctx))
+   return 1;
+
+   ibv_free_device_list(dev_list);
+   free(rem_dest);
+
return 0;
 }
Index: gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c
===
--- gen2_devel_user.orig/src/userspace/libibverbs/examples/srq_pingpong.c   
2007-01-17 10:58:02.0 +0200
+++ gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c
2007-01-17 11:10:31.0 +0200
@@ -358,7 +358,7 @@ static struct pingpong_context *pp_init_
 
ctx-mr = ibv_reg_mr(ctx-pd, ctx-buf, size, IBV_ACCESS_LOCAL_WRITE);
if (!ctx-mr) {
-   fprintf(stderr, Couldn't allocate MR\n);
+   fprintf(stderr, Couldn't register MR\n);
return NULL;
}
 
@@ -424,6 +424,55 @@ static struct pingpong_context *pp_init_
return ctx;
 }
 
+int pp_close_ctx(struct pingpong_context *ctx, int num_qp)
+{
+   int i;
+
+   for (i = 0; i  num_qp; ++i) {
+   if (ibv_destroy_qp(ctx-qp[i])) {
+   fprintf(stderr, Couldn't destroy QP[%d]\n, i);
+   return 1;
+   }
+   }
+
+   if (ibv_destroy_srq(ctx-srq)) {
+   fprintf(stderr, Couldn't destroy SRQ\n);
+   return 1;
+   }
+
+   if (ibv_destroy_cq(ctx-cq)) {
+   fprintf(stderr, Couldn't destroy CQ\n);
+   return 1;
+   }
+
+   if (ibv_dereg_mr(ctx-mr)) {
+   fprintf(stderr, Couldn't deregister MR\n);
+   return 1;
+   }
+
+   if (ibv_dealloc_pd(ctx-pd)) {
+   fprintf(stderr, Couldn't deallocate PD\n);
+   return 1;
+   }
+
+   if (ctx-channel) {
+   if (ibv_destroy_comp_channel(ctx-channel)) {
+   fprintf(stderr, Couldn't destroy completion 
channel\n);
+   return 1;
+   }
+   }
+
+   if (ibv_close_device(ctx-context)) {
+   fprintf(stderr, Couldn't release context\n);
+   return 1;
+   }
+
+   free(ctx-buf);
+   free(ctx);
+
+

Re: [openib-general] [srptools] [PATCH] style fix in asprintf result check

2007-01-17 Thread ishai

Applied,

Thanks
Ishai



___
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] [srptools] [PATCH] Added checks to memory allocation failure when using asprintf

2007-01-17 Thread ishai

Applied,

Thanks
Ishai


___
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] multicast code/merge status

2007-01-17 Thread Or Gerlitz

Sean Hefty wrote:
 sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the 
 QP and later --if-- the user joins a multicast group modify the qp 
 state with the group qkey and report it in the cma event such that the 
 consumer of the rdmacm would set this into his IB UD TX WR

 Changing the qkey would break its existing UD communication.

OK, so we have three use cases here for a UD QP

+1 used only for unicast
+2 used only for multicast
+3 used for both unicast and multicast

and my suggestion (default qkey, when join is completed do qp modify 
with the group qkey) would work fine for use cases

1 - since the user never joins to anything and
2 - same as it works in ipoib

so we are left with use case 3.

To make things simple, the solution i suggest is that that the RDMA CM 
would --not-- do this modify QP/QKEY (that is would set the 0x12345678 
qkey on the modify qp to init) and rather leave it to the RDMA CM 
consumer --if-- they wish to do so. However it will use the ipv4 
broadcast group qkey for doing mcast joins and report this qkey to the 
user in the ud param of the event.

So users that don't care about their qkey would never bother to do this 
modify qp and users who do care would do it and have to take caution if 
their QP is of type 3 (both unicast and mcast).

If you don't like this direction, your idea from below to have two 
option for group type - rdmacm or ipoib and have the consumer specify 
it, so for group type ipoib you will use the ipv4 brd qkey for both join 
and modify qp and for group type rdmacm you would just use the rdmacm 
qkey and do no modify qp - this is fine for us as well.

 Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see 
 mentioning of privileged QKEY.
 
  From RFC 4391 (ipoib RFC), 4.1:
 
  2. Q_Key
 
   It is RECOMMENDED that a controlled Q_Key be used with the
   high-order bit set.  This is to prevent non-privileged
   software from fabricating and sending out bogus IP datagrams.
 
 I don't know what qkey is actually assigned, however.

this (what qkey is assigned to the ipv4 broadcast group by different 
SAs) is orthogonal to the discussion we do here.

 I have some path forward related tasks that I would like to complete 
 before starting on this.  I hope to finish that before the end of this 
 week.  I don't want to rush on the multicast support and miss 
 something.  For the rdma cm, we may need to let the user set some 
 options when joining a multicast group.  Maybe something like: join type 
 (send-only or send-receive), group type (ipoib or rdma defined), etc.

As I see it, the group type (or having no types and being always 
interoperable with ipoib as i suggest above) seems easy to add to the 
current implementation and would put it in acceptable state for upstream 
pushing to 2.6.21 and inclusion in OFED 1.2 .

As for the join type, as i told you before, I think it should --not-- 
delay the upstream nor the ofed 1.2 push - if you have the time add this 
  to the user/kernel ABI and have ucma kernel return -EINVAL if someone 
attempts to to send-only join. And if you don't have the time for that, 
it can be added later.

Actually, as you can see in the ipoib code, it never does a 
send-only-non-member join, so my take here is that till the ipoib issue 
is resolved there is no reason to have this complexity in the rdmacm.

 I do plan on requesting that the core multicast changes to ib_sa and 
 ib_ipoib be pulled into 2.6.21.

This is great news but again I think the nobody perfect rule applies 
well here, the current rdmacm multicast support (which the little fixes 
we discuss over this thread) can be pushed to 2.6.21 and be enhanced later.

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] History change in srptools.git

2007-01-17 Thread ishai

Hi

I changed the history in srptools.git (Some e-mail addresses errors)
The change is only on the log information. The files was not changed.
The change: version 19c761889b9bd86abc027a13c1c6d0a96607fe79 become version 
2088b76f62cd0e94d2c8415a6a328dc818d200f1

If you are working on it you will need to perform rebase.
Sorry for any inconvenient.

Thanks
Ishai

___
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] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

2007-01-17 Thread Or Gerlitz

Tziporet Koren wrote:
 Or Gerlitz wrote:
 Tziporet Koren wrote:


   The bonding package would support: fresh (2.6.20) and some older 
 upstream kernels along with SLES10 and RH4 Ux (x=3 for sure)

   
 OK - please send us all the info once its ready
   General changes to the package:
 * Multicast - we wait for Voltaire and Sean to close all technical
   details - should be ready by the end of the week
 

 I have just sent Sean over the list a clarification email, if needed 
 we would be able to help doing the missing patches and i guess in a 
 combined effort this would be ready for the end of --next-- week

   
 Thanks - please work with MST  Vlad on integration
 what about the host side QoS code? i did not see an newer RFC nor 
 patch other then the RFC that was sent many months ago.

 We are going to update our low level driver (mthca) to support it. 

 Beside there should be a small change in CMA for this, and its specified 
 in the RFC.

I understand that the change involves letting the rdma cm know the SID 
when the consumer calls --rdma_resolve_route-- where today it get to 
know the SID when the consumer calls --rdma_connect-- . So this is not 
an internal RDMA CM change but rather also changes the API.

Same for SRP as the api of ib_sa_path_rec_get (that is the structure it 
gets as input) changes, the SRP code also changes.

Any, can you send the mthca and rdmacm/rdmacm-consumers changes as 
RFC/PATCH over the list before the actual code freeze???

As for the QoS RFC
(http://openib.org/pipermail/openib-general/2006-May/022331.html) sent 
by Eitan, one design issue I see there is how to deal with IB ULPs which 
do --not-- have a well known SID. So they call ib_cm_listen with 
IB_CM_ASSIGN_SERVICE_ID and get from the CM a service id to use, then 
they might do some out of band exchange of this SID before starting 
their connection establishment.

from include/rdma/ib_cm.h

 * @service_id: Service identifier matched against incoming connection
  *   and service ID resolution requests.  The service ID should be specified
  *   network-byte order.  If set to IB_CM_ASSIGN_SERVICE_ID, the CM will
  *   assign a service ID to the caller.

Typically this happens with MPI up to the extent that different ranks 
within the same job may get a different SID. One solution i was thinking 
of is to

+1 define --range-- (eg big enough to serve 1024 CM consumers) per ULP
+2 change the CM to support allocating SID in a range
+3 change the ULPs which use IB_CM_ASSIGN_SERVICE_ID to ask SID in the 
relevant range
+4 change the QoS manager at the SM side to support ranges

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

Re: [openib-general] multicast code/merge status

2007-01-17 Thread Or Gerlitz

Michael S. Tsirkin wrote:
 Quoting Sean Hefty [EMAIL PROTECTED]:
 Subject: Re: multicast code/merge status

 sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the QP 
 and later --if-- the user joins a multicast group modify the qp state 
 with the group qkey and report it in the cma event such that the 
 consumer of the rdmacm would set this into his IB UD TX WR
 Changing the qkey would break its existing UD communication.

 Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see 
 mentioning of privileged QKEY.
  From RFC 4391 (ipoib RFC), 4.1:

   2. Q_Key

It is RECOMMENDED that a controlled Q_Key be used with the
high-order bit set.  This is to prevent non-privileged
software from fabricating and sending out bogus IP datagrams.
 
 BTW, should we be worried that proposed extension (passing qkey in rdma cm 
 param
 list) seems to expose this qkey to non-privileged software?

As was said over related threads here and elsewhere, multicast has its 
in nature non safeties and having IB implement broadcast over multicast 
adds more in safety to the party.

Specifically, as Roland has commented, a user can attach his user space 
UD QP to the MGID of the ipv4 broadcast(if ipoib is running on this 
node it will join the group) and start making this IP subnet go crazy.

We only want interop with IPoIB and we don't need to join/attach the 
ipv4 broadcast group just have an option for the rdmacm to use its qkey 
for joins and later either the rdmacm or the consumer will also set this 
qkey into the QP and the UD TX WR

 Maybe a machanism should be in place to control access to this separately
 from regular rdma cm for RC QPs?

not following you here, how does qkey relates to RC QPs ?

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

Re: [openib-general] OFED ipoib_8111_to_2_6_16.patch

2007-01-17 Thread Or Gerlitz

Or Gerlitz wrote:
 Michael S. Tsirkin wrote:
 git log -Sneigh_destructor -- include/net/neighbour.h

 also, having that at (my) hand does not remove the need that you will 
 set a changelog/signature for the OFED ipoib related backport patch.

 Feel free to add that.

 Unless i miss something, we want all OFED kernel patches to meet 
 **basic** kernel working conversions, specifically that for each patch 
 there is a change log and an owner.

OK, I realize now that in OFED 1.1 out of 438 .patch files under 
kernel_patches only 103 of them have Signed-Off-by line and assuming 
this maps 1:1 to the files that have change log, i am not asking you to 
write now 335 change-logs/signed-off-by section.

However, since understanding this patch in detail is important to a peer 
member individual/company of the community (myself/Voltaire) and you 
being this patch owner and also having the OFED kernel patches 
maintainer chair, it makes sense that per our request you will put 5 
minutes of your time to write a change log.

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

Re: [openib-general] multicast code/merge status

2007-01-17 Thread Michael S. Tsirkin

  Maybe a machanism should be in place to control access to this separately
  from regular rdma cm for RC QPs?
 
 not following you here, how does qkey relates to RC QPs ?

Currently you can block userspace from creating QPs by unloading uverbs module.
Maybe we should make it possible to block creating UD QPs from userspace
as a separate security measure.


-- 
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] [PATCH 0/6] osm: QoS policy parser

2007-01-17 Thread Yevgeny Kliteynik

Hi Hal

The following series of six patches implements QoS policy file parser:

1. QoS parser Lex file
2. QoS parser Lex-generated c file
3. QoS parser grammar (Yacc) file
4. QoS parser Yacc-generated grammar c and h file
5. QoS parser header file that defines parse tree data structures 
6. Changes in makefiles and configure.in file for compiling QoS parser files

--
Yevgeny

Signed-off-by:  Yevgeny Kliteynik [EMAIL PROTECTED]
 

___
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 1/6] osm: QoS parser Lex file

2007-01-17 Thread Yevgeny Kliteynik

Hi Hal.

This patch is QoS parser Lex file

Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
---
 osm/opensm/osm_qos_parser.l |  245 +++
 1 files changed, 245 insertions(+), 0 deletions(-)

diff --git a/osm/opensm/osm_qos_parser.l b/osm/opensm/osm_qos_parser.l
new file mode 100644
index 000..73b2a29
--- /dev/null
+++ b/osm/opensm/osm_qos_parser.l
@@ -0,0 +1,245 @@
+%{
+/*
+ * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
+ * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+/*
+ * Abstract:
+ *Lexer of OSM QoS parser.
+ *
+ * Environment:
+ *Linux User Mode
+ *
+ * Author:
+ *Yevgeny Kliteynik, Mellanox
+ */
+
+#include opensm/osm_qos_parser.h
+#include opensm/osm_qos_parser_y.h
+
+#define SAVE_POS save_pos()
+static void save_pos();
+
+extern int column_num;
+extern int line_num;
+extern FILE * yyin;
+
+%}
+
+XML_VERSION_START \?
+XML_VERSION_END   \?
+QOS_POLICY_START  qos\-policy
+QOS_POLICY_END\/qos\-policy
+PORT_GROUPS_START port\-groups
+PORT_GROUPS_END   \/port\-groups
+PORT_GROUP_START  port\-group
+PORT_GROUP_END\/port\-group
+NAME_STARTname
+NAME_END  \/name
+USE_START use
+USE_END   \/use
+PORT_GUID_START   port\-guid
+PORT_GUID_END \/port\-guid
+PORT_NAME_START   port\-name
+PORT_NAME_END \/port\-name
+PARTITION_START   partition
+PARTITION_END \/partition
+NODE_TYPE_START   node\-type
+NODE_TYPE_END \/node\-type
+QOS_SETUP_START   qos\-setup
+QOS_SETUP_END \/qos\-setup
+SL2VL_TABLES_STARTsl2vl\-tables
+SL2VL_TABLES_END  \/sl2vl\-tables
+SL2VL_SCOPE_START sl2vl\-scope
+SL2VL_SCOPE_END   \/sl2vl\-scope
+GROUP_START   group
+GROUP_END \/group
+FROM_STARTfrom
+FROM_END  \/from
+TO_START  to
+TO_END\/to
+SL2VL_TABLE_START sl2vl\-table
+SL2VL_TABLE_END   \/sl2vl\-table
+ACROSS_START  across
+ACROSS_END\/across
+ACROSS_FROM_START across\-from
+ACROSS_FROM_END   \/across\-from
+ACROSS_TO_START   across\-to
+ACROSS_TO_END \/across\-to
+VLARB_TABLES_STARTvlarb\-tables
+VLARB_TABLES_END  \/vlarb\-tables
+VLARB_SCOPE_START vlarb\-scope
+VLARB_SCOPE_END   \/vlarb\-scope
+VLARB_HIGH_START  vlarb\-high
+VLARB_HIGH_END\/vlarb\-high
+VLARB_LOW_START   vlarb\-low
+VLARB_LOW_END \/vlarb\-low
+VLARB_HIGH_LIMIT_STARTvl\-high\-limit
+VLARB_HIGH_LIMIT_END  \/vl\-high\-limit
+QOS_LEVELS_START  qos\-levels
+QOS_LEVELS_END\/qos\-levels
+QOS_LEVEL_START   qos\-level
+QOS_LEVEL_END \/qos\-level
+SN_START  sn
+SN_END\/sn
+SL_START  sl
+SL_END\/sl
+CLASS_START   class
+CLASS_END \/class
+MTU_LIMIT_START   mtu\-limit
+MTU_LIMIT_END \/mtu\-limit
+RATE_LIMIT_START  rate\-limit
+RATE_LIMIT_END\/rate\-limit
+QOS_MATCH_RULES_START qos\-match\-rules
+QOS_MATCH_RULES_END   \/qos\-match\-rules
+QOS_MATCH_RULE_START  qos\-match\-rule
+QOS_MATCH_RULE_END\/qos\-match\-rule
+QOS_LEVEL_SN_START

[openib-general] [PATCH 5/6] osm: QoS parser header file that defines parse tree data structures

2007-01-17 Thread Yevgeny Kliteynik

Hi Hal

This patch is a QoS parser header file that defines parse tree data structures.

Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
---
 osm/include/opensm/osm_qos_parser.h |  172 +++
 1 files changed, 172 insertions(+), 0 deletions(-)

diff --git a/osm/include/opensm/osm_qos_parser.h 
b/osm/include/opensm/osm_qos_parser.h
new file mode 100644
index 000..4e27c8c
--- /dev/null
+++ b/osm/include/opensm/osm_qos_parser.h
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
+ * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ *  - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ *  - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+/*
+ * Abstract:
+ *Declaration of OSM QoS parser.
+ *
+ * Environment:
+ *Linux User Mode
+ *
+ * Author:
+ *Yevgeny Kliteynik, Mellanox
+ */
+
+#ifndef OSM_QOS_PARSER_H
+#define OSM_QOS_PARSER_H
+
+#include stdio.h
+#include assert.h
+#include stdlib.h
+#include string.h
+#include ctype.h
+#include iba/ib_types.h
+#include opensm/osm_log.h
+#include opensm/osm_opensm.h
+
+#define YYSTYPE char *
+
+#define OSM_QOS_NODE_TYPE_CA CA
+#define OSM_QOS_NODE_TYPE_SWITCH SWITCH
+#define OSM_QOS_NODE_TYPE_ROUTER ROUTER
+
+typedef enum {UNDEF, ROUTER, CA, SWITCH} node_type_t;
+
+/***/
+
+typedef struct osm_qos_string_vector_item_t_ {
+   cl_map_item_t   map_item;
+   char  * str;
+} osm_qos_string_vector_item_t;
+
+typedef struct osm_qos_uint64_vector_item_t_ {
+   cl_map_item_t   map_item;
+   uint64_tvalue;
+} osm_qos_uint64_vector_item_t;
+
+typedef struct osm_qos_uint32_vector_item_t_ {
+   cl_map_item_t   map_item;
+   uint32_tvalue;
+} osm_qos_uint32_vector_item_t;
+
+typedef struct osm_qos_vlarb_hl_vector_item_t_ {
+   cl_map_item_t   map_item;
+   uint32_tsl;
+   uint32_tcredits;
+} osm_qos_vlarb_hl_vector_item_t;
+
+/***/
+
+typedef struct osm_qos_port_group_t_ {
+   cl_map_item_tmap_item;
+   char   * name;
+   char   * use;
+   cl_ptr_vector_t  port_guids; /* vector of uint64_t */
+   cl_ptr_vector_t  port_names; /* vector of string   */
+   cl_ptr_vector_t  partitions; /* vector of string   */
+   cl_ptr_vector_t  node_types; /* vector of uint8_t  */
+} osm_qos_port_group_t;
+
+/***/
+
+typedef struct osm_qos_sl2vl_scope_t_ {
+   cl_map_item_tmap_item;
+   cl_ptr_vector_t  groups;  /* vector of string */
+   cl_ptr_vector_t  from;/* vector of string */
+   cl_ptr_vector_t  to;  /* vector of string */
+   cl_ptr_vector_t  across_from; /* vector of string */
+   cl_ptr_vector_t  across_to;   /* vector of string */
+   uint8_t  sl2vl_table[16];
+} osm_qos_sl2vl_scope_t;
+
+/***/
+
+typedef struct osm_qos_vlarb_scope_t_ {
+   cl_map_item_tmap_item;
+   cl_ptr_vector_t  groups;   /* vector of string */
+   cl_ptr_vector_t  across;   /* vector of string */
+   cl_ptr_vector_t  vlarb_highs;  /* vector of string */
+   cl_ptr_vector_t  vlarb_lows;   /* vector of string */
+   uint32_t vl_high_limit;
+} osm_qos_vlarb_scope_t;
+
+/***/
+
+typedef struct osm_qos_level_t_ {
+   cl_map_item_tmap_item;
+   char   * use;
+   uint32_t sn;
+   uint32_t sl;
+   uint32_t mtu_limit;
+   uint32_t rate_limit;
+   uint32_t class;
+} osm_qos_level_t;
+

[openib-general] [PATCH 6/6] osm: Compiling new QoS parser files

2007-01-17 Thread Yevgeny Kliteynik

Hi Hal

Patch for compiling new QoS parser files.

Signed-off-by: Yevgeny Kliteynik [EMAIL PROTECTED]
---
 osm/include/Makefile.am |2 ++
 osm/opensm/Makefile.am  |   16 +++-
 osm/opensm/configure.in |4 
 3 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/osm/include/Makefile.am b/osm/include/Makefile.am
index d6bdd84..62db6c2 100644
--- a/osm/include/Makefile.am
+++ b/osm/include/Makefile.am
@@ -118,6 +118,8 @@ EXTRA_DIST = \
$(srcdir)/opensm/osm_drop_mgr.h \
$(srcdir)/opensm/osm_port_info_rcv.h \
$(srcdir)/opensm/osm_state_mgr_ctrl.h \
+   $(srcdir)/opensm/osm_qos_parser.h \
+   $(srcdir)/opensm/osm_qos_parser_y.h \
$(srcdir)/complib/cl_thread_osd.h \
$(srcdir)/complib/cl_packon.h \
$(srcdir)/complib/cl_atomic_osd.h \
diff --git a/osm/opensm/Makefile.am b/osm/opensm/Makefile.am
index dd6dbae..7fff9d7 100644
--- a/osm/opensm/Makefile.am
+++ b/osm/opensm/Makefile.am
@@ -71,7 +71,21 @@ opensm_SOURCES = main.c osm_console.c os
 osm_ucast_mgr.c osm_ucast_updn.c \
 osm_ucast_file.c osm_ucast_ftree.c \
 osm_vl15intf.c osm_vl_arb_rcv.c \
-osm_vl_arb_rcv_ctrl.c st.c
+osm_vl_arb_rcv_ctrl.c st.c \
+osm_qos_parser_y.c osm_qos_parser_l.c
+
+osm_qos_parser_y.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/osm_qos_parser.y
+   $(YACC) -y -d $(srcdir)/osm_qos_parser.y
+   mv y.tab.c osm_qos_parser_y.c
+   mv y.tab.h osm_qos_parser_y.h
+   cp -f osm_qos_parser_y.c $(srcdir)/
+   cp -f osm_qos_parser_y.h $(srcdir)/../include/opensm/
+
+osm_qos_parser_l.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/osm_qos_parser.l
+   $(LEX) $(srcdir)/osm_qos_parser.l
+   mv lex.yy.c osm_qos_parser_l.c
+   cp -f osm_qos_parser_l.c $(srcdir)/
+
 if OSMV_OPENIB
 opensm_CFLAGS = -Wall $(OSMV_CFLAGS) -fno-strict-aliasing 
-DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP $(DBGFLAGS) -D_XOPEN_SOURCE=600 
-D_BSD_SOURCE=1
 opensm_CXXFLAGS = -Wall $(OSMV_CFLAGS) -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP 
$(DBGFLAGS) -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1
diff --git a/osm/opensm/configure.in b/osm/opensm/configure.in
index cecf932..496e806 100644
--- a/osm/opensm/configure.in
+++ b/osm/opensm/configure.in
@@ -14,6 +14,8 @@ if test -z $opensm_api_version; then
 fi
 AC_SUBST(opensm_api_version)
 
+AM_MAINTAINER_MODE
+
 dnl Checks for programs
 AC_PROG_CXX
 AC_PROG_CC
@@ -22,6 +24,8 @@ AC_PROG_INSTALL
 AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_LIBTOOL
+AM_PROG_LEX 
+AC_PROG_YACC
 
 dnl Checks for libraries
 
-- 
1.4.4.1.GIT


___
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] OpenIB Wiki pages updated

2007-01-17 Thread Vladimir Sokolovsky

Hi,
The following links were added to https://wiki.openfabrics.org/tiki-index.php:

OFED 1.2 HowTo
HOWTO Build OFA user package
HOWTO Build OFA kernel package
HOWTO add userspace package to ofa_user


Regards,
Vladimir


___
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/ipoib_cm: reduce MTU on connected-datagram mode change

2007-01-17 Thread Michael S. Tsirkin

UD mode requires MTU = broadcast group MTU, make sure MTU is valid
when switching back from connected mode.

Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]

---

Incremental patch on top of the IPoIB CM.
Pls apply in for-mm.

diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c 
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index bb6a9b1..43500fd 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -1127,6 +1127,7 @@ static ssize_t set_mode(struct class_device *cdev,
 
if (!strcmp(buf, datagram\n)) {
clear_bit(IPOIB_FLAG_ADMIN_CM, priv-flags);
+   dev-mtu = min(priv-mcast_mtu, dev-mtu);
ipoib_flush_paths(dev);
return count;
}
-- 
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 RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3

2007-01-17 Thread Steve WIse

 BTW, Steve, I wouldn't start working on backports from SLES9.
 I'd start with 2.6.19 and go back to 2.6.11 over kernel.org versions,
 just making sure they build (we have this build environment on 
 openfabrics.org,
 or its easy to check all versions out from kernel.org git).
 In this way you get incrementtall a host of data on what is and what isn't in
 which kernel version.
 
 Then adding support for a distro is just a matter of finding a closest
 kernel.org kernel and mostly removing stuff that distro backported from newer 
 kernels.
 

Michael,

Is there something magic about stopping at 2.6.11?  


___
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] OpenIB Wiki pages updated

2007-01-17 Thread Woodruff, Robert J

Vladimir wrote,
Hi,
The following links were added to
https://wiki.openfabrics.org/tiki-index.php:

OFED 1.2 HowTo
HOWTO Build OFA user package
HOWTO Build OFA kernel package
HOWTO add userspace package to ofa_user


Regards,
Vladimir

How do I make it build the rdma_cm and rdma_ucm, there appears to be no
configure
option in the ./configure script of the daily builds even though the
code is in
the core directory. ( I tried the 2/17/2007 kernel
daily build).

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

___
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] madeye

2007-01-17 Thread Raleigh F Rinehart

I'm trying to use madeye in OFED 1.1 Release to do some debugging but it 
does not seem to be present.  I cracked open src tarball and all the 
right bits seem to be there (Kconfig, makefile, src) but it doesn't seem 
to get built and installed as part of the normal installation procedure 
(running install.sh).  Has anyone had any success at building, 
installing and using madeye in a release version of OFED? 

thanks,
-raleigh


cat /usr/local/ofed/BUILD_ID
OFED-1.1

openib-1.1 (REV=9905)
# User space
https://openib.org/svn/gen2/branches/1.1/src/userspace
Git:
ref: refs/heads/ofed_1_1
commit a083ec1174cb4b5a5052ef5de9a8175df82e864a

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

uname -a
Linux merrill2 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

cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10


___
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] nightly osm_sim report 2007-01-15:normal completion

2007-01-17 Thread Hal Rosenstock

Hi Eitan,

On Mon, 2007-01-15 at 00:17, Eitan Zahavi wrote: 
 OSM Simulation Regression Summary
 OpenSM rev = Sat_Jan_13_09:43:14_2007 1f8015 
 ibutils rev = Wed_Jan_3_11:42:12_2007 913448 
 Total=410 Pass=409 Fail=1
 
 Pass:
 30 Stability IS1-16.topo
 30 Pkey IS1-16.topo
 30 OsmTest IS1-16.topo
 30 OsmStress IS1-16.topo
 30 Multicast IS1-16.topo
 30 LidMgr IS1-16.topo
 10 Stability IS3-loop.topo
 10 Stability IS3-128.topo
 10 Pkey IS3-128.topo
 10 OsmTest IS3-loop.topo
 10 OsmTest IS3-128.topo
 10 Multicast IS3-loop.topo
 10 Multicast IS3-128.topo
 10 LidMgr IS3-128.topo
 10 FatTree part-4-ary-3-tree.topo
 10 FatTree merge-roots-reorder-4-ary-2-tree.topo
 10 FatTree merge-roots-4-ary-2-tree.topo
 10 FatTree merge-root-4-ary-3-tree.topo
 10 FatTree merge-root-12-ary-2-tree.topo
 10 FatTree merge-2-ary-4-tree.topo
 10 FatTree half-4-ary-3-tree.topo
 10 FatTree blend-4-ary-2-tree.topo
 10 FatTree 4-ary-4-tree.topo
 10 FatTree 4-ary-3-tree.topo
 10 FatTree 32nodes-3lvl-is1.topo
 10 FatTree 2-ary-4-tree.topo
 10 FatTree 12-node-spaced.topo
 10 FatTree 12-ary-2-tree.topo
 9 OsmStress IS3-128.topo
 
 Failures:
 1 OsmStress IS3-128.topo

Any idea on this failure from a couple of days ago ? Will the other
previous failures still be investigated at some point ?

-- 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] multicast code/merge status

2007-01-17 Thread Sean Hefty

 +1 used only for unicast
 +2 used only for multicast
 +3 used for both unicast and multicast

If you view this as the use case for one side only, we also have option 3 
communicating with options 1 and 2.  I would list these as:

+4 unicast QP to unicast and multicast QP
+5 multicast QP to unicast and multicast QP

Today, all of these work.  What you're wanting to add is the ability to 
communicate with an ipoib multicast group.  I'd like to do this without 
breaking 
any of the existing communications, or treat ipoib separately for security 
reasons.

 To make things simple, the solution i suggest is that that the RDMA CM 
 would --not-- do this modify QP/QKEY (that is would set the 0x12345678 
 qkey on the modify qp to init) and rather leave it to the RDMA CM 
 consumer --if-- they wish to do so. However it will use the ipv4 
 broadcast group qkey for doing mcast joins and report this qkey to the 
 user in the ud param of the event.

We need to be able to handle options 4 and 5 as well.

 this (what qkey is assigned to the ipv4 broadcast group by different 
 SAs) is orthogonal to the discussion we do here.

This depends on whether verbs allows, or if it should allow, a user to specify 
a 
controlled qkey when configuring their QP.

- 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] madeye

2007-01-17 Thread Scott Weitzenkamp (sweitzen)

It's not well integrated into install.sh, you have to run:

OPENIB_PARAMS=--with-madeye-mod ./install.sh

Scott Weitzenkamp
SQA and Release Manager
Server Virtualization Business Unit
Cisco Systems
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Raleigh F Rinehart
 Sent: Wednesday, January 17, 2007 9:48 AM
 To: openib-general@openib.org
 Subject: [openib-general] madeye
 
 I'm trying to use madeye in OFED 1.1 Release to do some 
 debugging but it 
 does not seem to be present.  I cracked open src tarball and all the 
 right bits seem to be there (Kconfig, makefile, src) but it 
 doesn't seem 
 to get built and installed as part of the normal installation 
 procedure 
 (running install.sh).  Has anyone had any success at building, 
 installing and using madeye in a release version of OFED? 
 
 thanks,
 -raleigh
 
 
 cat /usr/local/ofed/BUILD_ID
 OFED-1.1
 
 openib-1.1 (REV=9905)
 # User space
 https://openib.org/svn/gen2/branches/1.1/src/userspace
 Git:
 ref: refs/heads/ofed_1_1
 commit a083ec1174cb4b5a5052ef5de9a8175df82e864a
 
 # MPI
 mpi_osu-0.9.7-mlx2.2.0.tgz
 openmpi-1.1.1-1.src.rpm
 mpitests-2.0-0.src.rpm
 
 uname -a
 Linux merrill2 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
 
 cat /etc/SuSE-release
 SUSE Linux Enterprise Server 10 (x86_64)
 VERSION = 10
 
 
 ___
 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] OpenIB Wiki pages updated

2007-01-17 Thread Steve WIse

try --with-addr_trans-mod


On Wed, 2007-01-17 at 09:41 -0800, Woodruff, Robert J wrote:
 Vladimir wrote,
 Hi,
 The following links were added to
 https://wiki.openfabrics.org/tiki-index.php:
 
 OFED 1.2 HowTo
 HOWTO Build OFA user package
 HOWTO Build OFA kernel package
 HOWTO add userspace package to ofa_user
 
 
 Regards,
 Vladimir
 
 How do I make it build the rdma_cm and rdma_ucm, there appears to be no
 configure
 option in the ./configure script of the daily builds even though the
 code is in
 the core directory. ( I tried the 2/17/2007 kernel
 daily build).
 
 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
 
 ___
 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] SDP performance

2007-01-17 Thread Eric Barton

Hi,

Does anyone have any performance measurements of SDP over OpenFabrics?

Can any of the SDP developers confirm that SDP can be zero-copy both on
sending and receiving?  If so, are there tunables that affect when to copy
and when not?

Cheers,
Eric

---
|Eric BartonBarton Software   |
|9 York Gardens Tel:+44 (117) 330 1575|
|CliftonMobile: +44 (7909) 680 356|
|Bristol BS8 4LLFax:call first|
|United Kingdom E-Mail: [EMAIL PROTECTED]|
---



___
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] multicast code/merge status

2007-01-17 Thread Or Gerlitz

On 1/17/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
  not following you here, how does qkey relates to RC QPs ?

 Currently you can block userspace from creating QPs by unloading uverbs 
 module.
 Maybe we should make it possible to block creating UD QPs from userspace
 as a separate security measure.

I don't think this is valid option for most of the IB production env.
but if you want to add blocking UD QP creation to ib_uverbs as  mod
param whose default value is --unset--,  i don't really care.

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

Re: [openib-general] multicast code/merge status

2007-01-17 Thread Or Gerlitz

On 1/17/07, Sean Hefty [EMAIL PROTECTED] wrote:
  +1 used only for unicast
  +2 used only for multicast
  +3 used for both unicast and multicast

 If you view this as the use case for one side only, we also have option 3
 communicating with options 1 and 2.  I would list these as:

OK

 +4 unicast QP to unicast and multicast QP

i think you mean 3 -- 1 that is unicast and multicast QP to unicast QP

 +5 multicast QP to unicast and multicast QP

i think you mean 3 -- 2 that is unicast and multicast QP to multicast QP

 Today, all of these work.  What you're wanting to add is the ability to
 communicate with an ipoib multicast group.  I'd like to do this without 
 breaking
 any of the existing communications, or treat ipoib separately for security 
 reasons.

makes sense, so my suggestion is leave this (using the ipoib qkey) to
the user
if you prefer to have two group types: rdmacm and ipoib - that's fine.
we would use ipoib type groups and in the envs that seting the qkey to
be the ipoib would not break our communication (that is where we do
need to interop with IPoIB) - we would do it, else we would do
nothing.

  To make things simple, the solution i suggest is that that the RDMA CM
  would --not-- do this modify QP/QKEY (that is would set the 0x12345678
  qkey on the modify qp to init) and rather leave it to the RDMA CM
  consumer --if-- they wish to do so. However it will use the ipv4
  broadcast group qkey for doing mcast joins and report this qkey to the
  user in the ud param of the event.

 We need to be able to handle options 4 and 5 as well.

indeed, i have addressed that above.

  this (what qkey is assigned to the ipv4 broadcast group by different
  SAs) is orthogonal to the discussion we do here.

 This depends on whether verbs allows, or if it should allow, a user to 
 specify a
 controlled qkey when configuring their QP.

I don't think there is any limitation today in the verbs layer,
actually for our testing so far we patches the rdmacm not set the sig
byte and use the ipoib (ie not override it in core/cma.c)  and we
manage to interop fine with ipoib.

___
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] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

2007-01-17 Thread Or Gerlitz

On 1/17/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
  Quoting Or Gerlitz [EMAIL PROTECTED]:

  I understand that the change involves letting the rdma cm know the SID
  when the consumer calls --rdma_resolve_route-- where today it get to
  know the SID when the consumer calls --rdma_connect-- . So this is not
  an internal RDMA CM change but rather also changes the API.

  Same for SRP as the api of ib_sa_path_rec_get (that is the structure it
  gets as input) changes, the SRP code also changes.

  Any, can you send the mthca and rdmacm/rdmacm-consumers changes as
  RFC/PATCH over the list before the actual code freeze???

 I didn't start on this code yet, but it does not look like a
 huge project, I hope to post code by next week.

 To avoid major disruptions all over the stack, my preference for OFED 1.2
 would be to add new API calls and a module option (off by default) for cma/srp
 to use them.

the rdmacm api change is not such a big deal and if you want to change
it only for the kernel portion for the ofed 1.2 it makes sense to me.
I really don't think --adding-- a special api is the way to go. Doing
it in end in mind fashion, work on a patch, send it to the rdmacm
maintainer/list for RFC and so on.

 For OFED 1.2, I only planned to implement this for SDP and SRP.
 I do not expect all this to be mergeable in 2.6.21 time frame,
 so maybe that's enough.

SDP is coded over the RDMA CM and i say above my suggestion is not to
add a special API, so just dp the same QoS patching you do to SDP to
iSER etc.

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

Re: [openib-general] [PATCH] opensm: fix segfault with up/down and root nodes file.

2007-01-17 Thread Hal Rosenstock

On Tue, 2007-01-09 at 18:21, Sasha Khapyorsky wrote: 
 Segfault happens when yet non-initialized lid_matrix tables are
 accessed - with up/down routing engine when root nodes are provided by
 user and lid matrices are not pre-created. There is the fix.
 
 Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]

Thanks. Applied.

-- 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] multicast code/merge status

2007-01-17 Thread Sean Hefty

 makes sense, so my suggestion is leave this (using the ipoib qkey) to
 the user

This is fine, but it may change when the user needs to make this choice.  E.g. 
when creating the QP, versus joining the multicast group, in order to support 
the valid options.  The selection also needs to be conveyed to the kernel 
somehow.  At this point, maybe we just need to start looking at specific 
implementations.

 I don't think there is any limitation today in the verbs layer,
 actually for our testing so far we patches the rdmacm not set the sig
 byte and use the ipoib (ie not override it in core/cma.c)  and we
 manage to interop fine with ipoib.

Maybe this shouldn't be allowed for any random application.  Perhaps there's a 
way to treat controlled qkeys similar to the privileged port space.

- 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] [PATCH RFC 00/10] ofed_1_2 - Chelsio backports

2007-01-17 Thread Steve Wise


Michael,

I took your advice and backported the chelsio code to kernel.org kernels
2.6.19 through 2.6.11 and then to sles9sp3.  Attached are the patches,
one for each kernel.org version.

Please review.  

Thanks,

Steve.

___
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 RFC 04/10] ofed_1_2 Chelsio backport to 2.6.16

2007-01-17 Thread Steve Wise


Chelsio backport to 2.6.16

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.16/include/linux/genalloc.h   |   42 +
 .../backport/2.6.16/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.16/include/linux/netdevice.h  |4 
 .../backport/2.6.16/include/linux/random.h |   15 ++
 .../backport/2.6.16/include/linux/skbuff.h |3 
 .../backport/2.6.16/include/linux/workqueue.h  |9 +
 .../backport/2.6.16/include/net/netevent.h |   33 
 .../backport/2.6.16/include/src/genalloc.c |  198 
+++
 .../backport/2.6.16/include/src/netevent.c |   71 
 .../backport/2.6.16/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.16/linux_stuff_to_2_6_17.patch|   24 +++
 11 files changed, 427 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.16/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.16/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.16/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.16/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.16/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.16/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.16/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.16/include/linux/netdevice.h
index 5641019..225eeda 100644
--- a/kernel_addons/backport/2.6.16/include/linux/netdevice.h
+++ b/kernel_addons/backport/2.6.16/include/linux/netdevice.h
@@ -15,4 +15,8 @@ static inline void netif_tx_unlock(struc
spin_unlock(dev-xmit_lock);
 }
 
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
 #endif
diff --git a/kernel_addons/backport/2.6.16/include/linux/random.h 
b/kernel_addons/backport/2.6.16/include/linux/random.h
new file mode 100644
index 000..2ea2e1f
--- /dev/null
+++ b/kernel_addons/backport/2.6.16/include/linux/random.h
@@ -0,0 +1,15 @@
+#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18
+#define BACKPORT_LINUX_RANDOM_TO_2_6_18
+#include_next linux/random.h
+
+static inline u32 backport_random32(void)
+{
+   u32 v;
+
+   get_random_bytes(v, sizeof(u32));
+   return v;
+}
+
+#define random32 backport_random32
+
+#endif
diff --git a/kernel_addons/backport/2.6.16/include/linux/skbuff.h 
b/kernel_addons/backport/2.6.16/include/linux/skbuff.h
index 4845283..70bf011 100644
--- a/kernel_addons/backport/2.6.16/include/linux/skbuff.h
+++ b/kernel_addons/backport/2.6.16/include/linux/skbuff.h
@@ -4,5 +4,8 @@ #define LINUX_SKBUFF_H_BACKPORT
 #include_next linux/skbuff.h
 
 #define CHECKSUM_PARTIAL CHECKSUM_HW 
+#define CHECKSUM_COMPLETE CHECKSUM_HW 
+
+#define gso_size

[openib-general] [PATCH RFC 02/10] ofed_1_2 Chelsio backport to 2.6.18

2007-01-17 Thread Steve Wise


Chelsio backport to 2.6.18

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.18/include/linux/genalloc.h   |   42 +
 .../backport/2.6.18/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.18/include/linux/netdevice.h  |9 +
 .../backport/2.6.18/include/linux/random.h |   15 ++
 .../backport/2.6.18/include/linux/skbuff.h |1 
 .../backport/2.6.18/include/linux/workqueue.h  |9 +
 .../backport/2.6.18/include/src/genalloc.c |  198 
+++
 .../backport/2.6.18/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.18/linux_genalloc_to_2_6_20.patch |   17 ++
 9 files changed, 319 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.18/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.18/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.18/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.18/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.18/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.18/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.18/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.18/include/linux/netdevice.h
new file mode 100644
index 000..61a6deb
--- /dev/null
+++ b/kernel_addons/backport/2.6.18/include/linux/netdevice.h
@@ -0,0 +1,9 @@
+#ifndef BACKPORT_LINUX_NETDEVICE_TO_2_6_18
+#define BACKPORT_LINUX_NETDEVICE_TO_2_6_18
+#include_next linux/netdevice.h
+
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
+#endif
diff --git a/kernel_addons/backport/2.6.18/include/linux/random.h 
b/kernel_addons/backport/2.6.18/include/linux/random.h
new file mode 100644
index 000..2ea2e1f
--- /dev/null
+++ b/kernel_addons/backport/2.6.18/include/linux/random.h
@@ -0,0 +1,15 @@
+#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18
+#define BACKPORT_LINUX_RANDOM_TO_2_6_18
+#include_next linux/random.h
+
+static inline u32 backport_random32(void)
+{
+   u32 v;
+
+   get_random_bytes(v, sizeof(u32));
+   return v;
+}
+
+#define random32 backport_random32
+
+#endif
diff --git a/kernel_addons/backport/2.6.18/include/linux/skbuff.h 
b/kernel_addons/backport/2.6.18/include/linux/skbuff.h
index 4845283..ca5edc0 100644
--- a/kernel_addons/backport/2.6.18/include/linux/skbuff.h
+++ b/kernel_addons/backport/2.6.18/include/linux/skbuff.h
@@ -4,5 +4,6 @@ #define LINUX_SKBUFF_H_BACKPORT
 #include_next linux/skbuff.h
 
 #define CHECKSUM_PARTIAL CHECKSUM_HW 
+#define CHECKSUM_COMPLETE CHECKSUM_HW 
 
 #endif
diff --git a/kernel_addons/backport/2.6.18/include/linux/workqueue.h 
b/kernel_addons/backport/2.6.18/include/linux/workqueue.h
index

[openib-general] [PATCH RFC 03/10] ofed_1_2 Chelsio backport to 2.6.17

2007-01-17 Thread Steve Wise


Chelsio backport to 2.6.17

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.17/include/linux/genalloc.h   |   42 +
 .../backport/2.6.17/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.17/include/linux/netdevice.h  |4 
 .../backport/2.6.17/include/linux/random.h |   15 ++
 .../backport/2.6.17/include/linux/skbuff.h |3 
 .../backport/2.6.17/include/linux/workqueue.h  |9 +
 .../backport/2.6.17/include/net/netevent.h |   33 
 .../backport/2.6.17/include/src/genalloc.c |  198 
+++
 .../backport/2.6.17/include/src/netevent.c |   69 
 .../backport/2.6.17/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.17/linux_stuff_to_2_6_17.patch|   24 +++
 11 files changed, 425 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.17/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.17/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.17/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.17/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.17/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.17/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.17/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.17/include/linux/netdevice.h
index 5641019..225eeda 100644
--- a/kernel_addons/backport/2.6.17/include/linux/netdevice.h
+++ b/kernel_addons/backport/2.6.17/include/linux/netdevice.h
@@ -15,4 +15,8 @@ static inline void netif_tx_unlock(struc
spin_unlock(dev-xmit_lock);
 }
 
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
 #endif
diff --git a/kernel_addons/backport/2.6.17/include/linux/random.h 
b/kernel_addons/backport/2.6.17/include/linux/random.h
new file mode 100644
index 000..2ea2e1f
--- /dev/null
+++ b/kernel_addons/backport/2.6.17/include/linux/random.h
@@ -0,0 +1,15 @@
+#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18
+#define BACKPORT_LINUX_RANDOM_TO_2_6_18
+#include_next linux/random.h
+
+static inline u32 backport_random32(void)
+{
+   u32 v;
+
+   get_random_bytes(v, sizeof(u32));
+   return v;
+}
+
+#define random32 backport_random32
+
+#endif
diff --git a/kernel_addons/backport/2.6.17/include/linux/skbuff.h 
b/kernel_addons/backport/2.6.17/include/linux/skbuff.h
index 4845283..70bf011 100644
--- a/kernel_addons/backport/2.6.17/include/linux/skbuff.h
+++ b/kernel_addons/backport/2.6.17/include/linux/skbuff.h
@@ -4,5 +4,8 @@ #define LINUX_SKBUFF_H_BACKPORT
 #include_next linux/skbuff.h
 
 #define CHECKSUM_PARTIAL CHECKSUM_HW 
+#define CHECKSUM_COMPLETE CHECKSUM_HW 
+
+#define gso_size

[openib-general] [PATCH RFC 06/10] ofed_1_2 Backport chelsio to 2.6.14

2007-01-17 Thread Steve Wise


Backport chelsio to 2.6.14

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.14/include/linux/genalloc.h   |   42 +
 .../backport/2.6.14/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.14/include/linux/netdevice.h  |9 +
 .../backport/2.6.14/include/linux/random.h |   15 ++
 .../backport/2.6.14/include/linux/skbuff.h |3 
 .../backport/2.6.14/include/linux/types.h  |6 +
 .../backport/2.6.14/include/linux/workqueue.h  |9 +
 .../backport/2.6.14/include/net/netevent.h |   33 
 .../backport/2.6.14/include/src/genalloc.c |  198 
+++
 .../backport/2.6.14/include/src/netevent.c |   71 
 .../backport/2.6.14/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.14/linux_stuff_to_2_6_17.patch|   24 +++
 12 files changed, 438 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.14/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.14/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.14/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.14/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.14/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.14/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.14/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.14/include/linux/netdevice.h
index 5641019..2f12781 100644
--- a/kernel_addons/backport/2.6.14/include/linux/netdevice.h
+++ b/kernel_addons/backport/2.6.14/include/linux/netdevice.h
@@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc
spin_unlock(dev-xmit_lock);
 }
 
+static inline int __netif_rx_schedule_prep(struct net_device *dev)
+{
+return !test_and_set_bit(__LINK_STATE_RX_SCHED, dev-state);
+}
+
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
 #endif
diff --git a/kernel_addons/backport/2.6.14/include/linux/random.h 
b/kernel_addons/backport/2.6.14/include/linux/random.h
new file mode 100644
index 000..2ea2e1f
--- /dev/null
+++ b/kernel_addons/backport/2.6.14/include/linux/random.h
@@ -0,0 +1,15 @@
+#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18
+#define BACKPORT_LINUX_RANDOM_TO_2_6_18
+#include_next linux/random.h
+
+static inline u32 backport_random32(void)
+{
+   u32 v;
+
+   get_random_bytes(v, sizeof(u32));
+   return v;
+}
+
+#define random32 backport_random32
+
+#endif
diff --git a/kernel_addons/backport/2.6.14/include/linux/skbuff.h 
b/kernel_addons/backport/2.6.14/include/linux/skbuff.h
index 4845283..70bf011 100644
--- a/kernel_addons/backport/2.6.14/include/linux/skbuff.h
+++

[openib-general] [PATCH RFC 08/10] ofed_1_2 Backport Chelsio to 2.6.12

2007-01-17 Thread Steve Wise


Backport Chelsio to 2.6.12

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.12/include/linux/ethtool.h|9 +
 .../backport/2.6.12/include/linux/genalloc.h   |   42 +
 .../backport/2.6.12/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.12/include/linux/netdevice.h  |9 +
 .../backport/2.6.12/include/linux/random.h |   15 ++
 .../backport/2.6.12/include/linux/skbuff.h |3 
 .../backport/2.6.12/include/linux/types.h  |2 
 .../backport/2.6.12/include/linux/workqueue.h  |9 +
 .../backport/2.6.12/include/net/netevent.h |   33 
 .../backport/2.6.12/include/src/genalloc.c |  198 
+++
 .../backport/2.6.12/include/src/netevent.c |   71 
 .../backport/2.6.12/cxgb3_main_to_2_6_13.patch |   12 +
 .../backport/2.6.12/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.12/linux_stuff_to_2_6_17.patch|   24 +++
 .../backport/2.6.12/t3_hw_to_2_6_13.patch  |   13 ++
 15 files changed, 468 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.12/include/linux/ethtool.h 
b/kernel_addons/backport/2.6.12/include/linux/ethtool.h
new file mode 100644
index 000..d03127c
--- /dev/null
+++ b/kernel_addons/backport/2.6.12/include/linux/ethtool.h
@@ -0,0 +1,9 @@
+#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+
+#include_next linux/ethtool.h
+
+#define ADVERTISED_Pause   (1  13)
+#define ADVERTISED_Asym_Pause  (1  14)
+
+#endif
diff --git a/kernel_addons/backport/2.6.12/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.12/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.12/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.12/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.12/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.12/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.12/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.12/include/linux/netdevice.h
index 5641019..2f12781 100644
--- a/kernel_addons/backport/2.6.12/include/linux/netdevice.h
+++ b/kernel_addons/backport/2.6.12/include/linux/netdevice.h
@@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc
spin_unlock(dev-xmit_lock);
 }
 
+static inline int __netif_rx_schedule_prep(struct net_device *dev)
+{
+return !test_and_set_bit(__LINK_STATE_RX_SCHED, dev-state);
+}
+
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
 #endif
diff --git a/kernel_addons/backport/2.6.12/include/linux/random.h

[openib-general] [PATCH RFC 05/10] ofed_1_2 Backport cxgb3 to 2.6.15

2007-01-17 Thread Steve Wise


Backport cxgb3 to 2.6.15

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.15/include/linux/genalloc.h   |   42 +
 .../backport/2.6.15/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.15/include/linux/netdevice.h  |9 +
 .../backport/2.6.15/include/linux/random.h |   15 ++
 .../backport/2.6.15/include/linux/skbuff.h |3 
 .../backport/2.6.15/include/linux/types.h  |6 +
 .../backport/2.6.15/include/linux/workqueue.h  |9 +
 .../backport/2.6.15/include/net/netevent.h |   33 
 .../backport/2.6.15/include/src/genalloc.c |  198 
+++
 .../backport/2.6.15/include/src/netevent.c |   71 
 .../backport/2.6.15/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.15/linux_stuff_to_2_6_17.patch|   24 +++
 12 files changed, 438 insertions(+), 1 deletions(-)

diff --git a/kernel_addons/backport/2.6.15/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.15/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.15/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.15/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.15/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.15/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.15/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.15/include/linux/netdevice.h
index 5641019..2f12781 100644
--- a/kernel_addons/backport/2.6.15/include/linux/netdevice.h
+++ b/kernel_addons/backport/2.6.15/include/linux/netdevice.h
@@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc
spin_unlock(dev-xmit_lock);
 }
 
+static inline int __netif_rx_schedule_prep(struct net_device *dev)
+{
+return !test_and_set_bit(__LINK_STATE_RX_SCHED, dev-state);
+}
+
+#undef SET_ETHTOOL_OPS
+#define SET_ETHTOOL_OPS(netdev, ops) \
+   (netdev)-ethtool_ops = (struct ethtool_ops *)(ops)
+
 #endif
diff --git a/kernel_addons/backport/2.6.15/include/linux/random.h 
b/kernel_addons/backport/2.6.15/include/linux/random.h
new file mode 100644
index 000..2ea2e1f
--- /dev/null
+++ b/kernel_addons/backport/2.6.15/include/linux/random.h
@@ -0,0 +1,15 @@
+#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18
+#define BACKPORT_LINUX_RANDOM_TO_2_6_18
+#include_next linux/random.h
+
+static inline u32 backport_random32(void)
+{
+   u32 v;
+
+   get_random_bytes(v, sizeof(u32));
+   return v;
+}
+
+#define random32 backport_random32
+
+#endif
diff --git a/kernel_addons/backport/2.6.15/include/linux/skbuff.h 
b/kernel_addons/backport/2.6.15/include/linux/skbuff.h
index 4845283..70bf011 100644
--- a/kernel_addons/backport/2.6.15/include/linux/skbuff.h
+++

[openib-general] [PATCH RFC 10/10] ofed_1_2 Backport Chelsio to sles9sp3

2007-01-17 Thread Steve Wise


Backport Chelsio to sles9sp3

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../2.6.5_sles9_sp3/include/linux/ethtool.h|9 +
 .../2.6.5_sles9_sp3/include/linux/genalloc.h   |   42 +
 .../2.6.5_sles9_sp3/include/linux/interrupt.h  |   17 ++
 .../backport/2.6.5_sles9_sp3/include/linux/kfifo.h |  157 ++
 .../backport/2.6.5_sles9_sp3/include/linux/mii.h   |   18 ++
 .../backport/2.6.5_sles9_sp3/include/linux/mm.h|   20 ++
 .../2.6.5_sles9_sp3/include/linux/netdevice.h  |   13 ++
 .../backport/2.6.5_sles9_sp3/include/linux/pci.h   |2 
 .../2.6.5_sles9_sp3/include/linux/random.h |   15 ++
 .../2.6.5_sles9_sp3/include/linux/skbuff.h |3 
 .../backport/2.6.5_sles9_sp3/include/linux/slab.h  |   19 --
 .../2.6.5_sles9_sp3/include/linux/spinlock.h   |8 +
 .../backport/2.6.5_sles9_sp3/include/linux/types.h |2 
 .../2.6.5_sles9_sp3/include/linux/workqueue.h  |8 +
 .../backport/2.6.5_sles9_sp3/include/net/dst.h |   17 ++
 .../2.6.5_sles9_sp3/include/net/neighbour.h|7 +
 .../2.6.5_sles9_sp3/include/net/netevent.h |   33 
 .../2.6.5_sles9_sp3/include/src/genalloc.c |  198 
+++
 .../backport/2.6.5_sles9_sp3/include/src/kfifo.c   |  196 
+++
 .../2.6.5_sles9_sp3/include/src/netevent.c |   71 
 .../2.6.5_sles9_sp3/cxgb3_main_to_2_6_13.patch |   12 +
 .../2.6.5_sles9_sp3/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../2.6.5_sles9_sp3/iwch_cm_to_2_6_5-7_244.patch   |   35 
 .../linux_stream_idr_to_2_6_5-7_244.patch  |   25 ---
 .../linux_stuff_to_2_6_5-7_244.patch   |   46 +
 .../mthca_provider_3465_to_2_6_9.patch |   15 --
 .../2.6.5_sles9_sp3/t3_hw_to_2_6_5-7_244.patch |   43 +
 27 files changed, 985 insertions(+), 58 deletions(-)

diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h 
b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h
new file mode 100644
index 000..d03127c
--- /dev/null
+++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h
@@ -0,0 +1,9 @@
+#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+
+#include_next linux/ethtool.h
+
+#define ADVERTISED_Pause   (1  13)
+#define ADVERTISED_Asym_Pause  (1  14)
+
+#endif
diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+

[openib-general] [PATCH RFC 09/10] ofed_1_2 Backport Chelsio to 2.6.11

2007-01-17 Thread Steve Wise


Backport Chelsio to 2.6.11

Signed-off-by: Steve Wise [EMAIL PROTECTED]
---

 .../backport/2.6.11/include/linux/ethtool.h|9 +
 .../backport/2.6.11/include/linux/genalloc.h   |   42 +
 .../backport/2.6.11/include/linux/interrupt.h  |   17 ++
 kernel_addons/backport/2.6.11/include/linux/mm.h   |8 +
 .../backport/2.6.11/include/linux/netdevice.h  |9 +
 .../backport/2.6.11/include/linux/random.h |   15 ++
 .../backport/2.6.11/include/linux/skbuff.h |2 
 kernel_addons/backport/2.6.11/include/linux/slab.h |   19 --
 .../backport/2.6.11/include/linux/types.h  |2 
 .../backport/2.6.11/include/linux/workqueue.h  |8 +
 kernel_addons/backport/2.6.11/include/net/dst.h|   16 ++
 .../backport/2.6.11/include/net/netevent.h |   33 
 .../backport/2.6.11/include/src/genalloc.c |  198 
+++
 .../backport/2.6.11/include/src/netevent.c |   71 
 .../backport/2.6.11/cxgb3_main_to_2_6_13.patch |   12 +
 .../backport/2.6.11/cxgb3_makefile_to_2_6_19.patch |   12 +
 .../backport/2.6.11/linux_stuff_to_2_6_17.patch|   24 +++
 .../2.6.11/mthca_provider_3465_to_2_6_11.patch |   13 --
 .../backport/2.6.11/t3_hw_to_2_6_13.patch  |   13 ++
 19 files changed, 492 insertions(+), 31 deletions(-)

diff --git a/kernel_addons/backport/2.6.11/include/linux/ethtool.h 
b/kernel_addons/backport/2.6.11/include/linux/ethtool.h
new file mode 100644
index 000..d03127c
--- /dev/null
+++ b/kernel_addons/backport/2.6.11/include/linux/ethtool.h
@@ -0,0 +1,9 @@
+#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13
+
+#include_next linux/ethtool.h
+
+#define ADVERTISED_Pause   (1  13)
+#define ADVERTISED_Asym_Pause  (1  14)
+
+#endif
diff --git a/kernel_addons/backport/2.6.11/include/linux/genalloc.h 
b/kernel_addons/backport/2.6.11/include/linux/genalloc.h
new file mode 100644
index 000..3c23c68
--- /dev/null
+++ b/kernel_addons/backport/2.6.11/include/linux/genalloc.h
@@ -0,0 +1,42 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+
+/*
+ *  General purpose special memory pool descriptor.
+ */
+struct gen_pool {
+   rwlock_t lock;
+   struct list_head chunks;/* list of chunks in this pool */
+   int min_alloc_order;/* minimum allocation order */
+};
+
+/*
+ *  General purpose special memory pool chunk descriptor.
+ */
+struct gen_pool_chunk {
+   spinlock_t lock;
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start_addr;   /* starting address of memory chunk */
+   unsigned long end_addr; /* ending address of memory chunk */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+extern struct gen_pool *ib_gen_pool_create(int, int);
+extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern void ib_gen_pool_destroy(struct gen_pool *);
+extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t);
+extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t);
+
+#define gen_pool_create ib_gen_pool_create
+#define gen_pool_add ib_gen_pool_add
+#define gen_pool_destroy ib_gen_pool_destroy
+#define gen_pool_alloc ib_gen_pool_alloc
+#define gen_pool_free ib_gen_pool_free
diff --git a/kernel_addons/backport/2.6.11/include/linux/interrupt.h 
b/kernel_addons/backport/2.6.11/include/linux/interrupt.h
new file mode 100644
index 000..66e66a9
--- /dev/null
+++ b/kernel_addons/backport/2.6.11/include/linux/interrupt.h
@@ -0,0 +1,17 @@
+#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18
+#include_next linux/interrupt.h
+
+static inline int 
+backport_request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *),
+ unsigned long flags, const char *dev_name, void *dev_id)
+{
+   return request_irq(irq, 
+  (irqreturn_t (*)(int, void *, struct pt_regs 
*))handler, 
+  flags, dev_name, dev_id);
+}
+
+#define request_irq backport_request_irq
+
+#endif
diff --git a/kernel_addons/backport/2.6.11/include/linux/mm.h 
b/kernel_addons/backport/2.6.11/include/linux/mm.h
new file mode 100644
index 000..1a1cf11
--- /dev/null
+++ b/kernel_addons/backport/2.6.11/include/linux/mm.h
@@ -0,0 +1,8 @@
+#ifndef BACKPORT_LINUX_MM_TO_2_6_11
+#define BACKPORT_LINUX_MM_TO_2_6_11
+
+#include_next linux/mm.h
+
+#define io_remap_pfn_range remap_pfn_range
+
+#endif
diff --git a/kernel_addons/backport/2.6.11/include/linux/netdevice.h 
b/kernel_addons/backport/2.6.11/include/linux/netdevice.h

[openib-general] SVN deprication

2007-01-17 Thread Arkady Kanevsky

Jeff and Co,
Is there a way to find out the date of a specific SVN revision #?
I can no longer access svn:
svn info -r 5400 https://openfabric.org/svn
svn: PROPFIND request failed on '/svn'
svn: PROPFIND of '/svn': could not connect to server (https://openfabric.org)

Is the SVN server depricated for good?
Do we have an SVN log somewhere in a git?
If yes, how can I find the correlation between Linux version and SVN revision?
Thanks,
Arkady

___
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 RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3

2007-01-17 Thread Michael S. Tsirkin

 Quoting Steve WIse [EMAIL PROTECTED]:
 Subject: Re: [PATCH RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3
 
  BTW, Steve, I wouldn't start working on backports from SLES9.
  I'd start with 2.6.19 and go back to 2.6.11 over kernel.org versions,
  just making sure they build (we have this build environment on 
  openfabrics.org,
  or its easy to check all versions out from kernel.org git).
  In this way you get incrementtall a host of data on what is and what isn't 
  in
  which kernel version.
  
  Then adding support for a distro is just a matter of finding a closest
  kernel.org kernel and mostly removing stuff that distro backported from 
  newer kernels.
  
 
 Michael,
 
 Is there something magic about stopping at 2.6.11?  

Yes. AFAIK IB subsystem was added to upstream kernel in 2.6.11.
So our kernel.org support has grown historically from there,
and we just added a couple of older distro kernels.

-- 
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] SVN deprication

2007-01-17 Thread Jeff Squyres

SVN is still available, but it is at a new URL:

 https://svn.openfabrics.org/svn/openib.

All the history and everything should be there; let me know if you  
have any problems.


On Jan 17, 2007, at 3:11 PM, Arkady Kanevsky wrote:

 Jeff and Co,
 Is there a way to find out the date of a specific SVN revision #?
 I can no longer access svn:
 svn info -r 5400 https://openfabric.org/svn
 svn: PROPFIND request failed on '/svn'
 svn: PROPFIND of '/svn': could not connect to server (https:// 
 openfabric.org)

 Is the SVN server depricated for good?
 Do we have an SVN log somewhere in a git?
 If yes, how can I find the correlation between Linux version and  
 SVN revision?
 Thanks,
 Arkady

 ___
 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


-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems


___
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] SVN deprication

2007-01-17 Thread Kanevsky, Arkady


Thanks Jeff.
This works.

Arkady Kanevsky   email: [EMAIL PROTECTED]
Network Appliance Inc.   phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195
Waltham, MA 02451   central phone: 781-768-5300
 

 -Original Message-
 From: Jeff Squyres [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, January 17, 2007 3:30 PM
 To: Kanevsky, Arkady
 Cc: openib-general@openib.org
 Subject: Re: [openib-general] SVN deprication
 
 SVN is still available, but it is at a new URL:
 
  https://svn.openfabrics.org/svn/openib.
 
 All the history and everything should be there; let me know 
 if you have any problems.
 
 
 On Jan 17, 2007, at 3:11 PM, Arkady Kanevsky wrote:
 
  Jeff and Co,
  Is there a way to find out the date of a specific SVN revision #?
  I can no longer access svn:
  svn info -r 5400 https://openfabric.org/svn
  svn: PROPFIND request failed on '/svn'
  svn: PROPFIND of '/svn': could not connect to server (https://
  openfabric.org)
 
  Is the SVN server depricated for good?
  Do we have an SVN log somewhere in a git?
  If yes, how can I find the correlation between Linux 
 version and SVN 
  revision?
  Thanks,
  Arkady
 
  ___
  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
 
 
 -- 
 Jeff Squyres
 Server Virtualization Business Unit
 Cisco Systems
 

___
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] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

2007-01-17 Thread Michael S. Tsirkin

 Quoting Or Gerlitz [EMAIL PROTECTED]:
 Subject: Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 
 teleconference about OFED 1.2 development progress toward code freeze
 
 On 1/17/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
   Quoting Or Gerlitz [EMAIL PROTECTED]:
 
   I understand that the change involves letting the rdma cm know the SID
   when the consumer calls --rdma_resolve_route-- where today it get to
   know the SID when the consumer calls --rdma_connect-- . So this is not
   an internal RDMA CM change but rather also changes the API.
 
   Same for SRP as the api of ib_sa_path_rec_get (that is the structure it
   gets as input) changes, the SRP code also changes.
 
   Any, can you send the mthca and rdmacm/rdmacm-consumers changes as
   RFC/PATCH over the list before the actual code freeze???
 
  I didn't start on this code yet, but it does not look like a
  huge project, I hope to post code by next week.
 
  To avoid major disruptions all over the stack, my preference for OFED 1.2
  would be to add new API calls and a module option (off by default) for 
  cma/srp
  to use them.
 
 the rdmacm api change is not such a big deal and if you want to change
 it only for the kernel portion for the ofed 1.2 it makes sense to me.
 I really don't think --adding-- a special api is the way to go. Doing
 it in end in mind fashion, work on a patch, send it to the rdmacm
 maintainer/list for RFC and so on.
 
  For OFED 1.2, I only planned to implement this for SDP and SRP.
  I do not expect all this to be mergeable in 2.6.21 time frame,
  so maybe that's enough.
 
 SDP is coded over the RDMA CM and i say above my suggestion is not to
 add a special API, so just dp the same QoS patching you do to SDP to
 iSER etc.

Sounds too risky to me, this is technology preview code so
I want to have all this stuff off by default but easily
enabled by users who want to demo.

After I post the rest of the code, if you like you'll be able to
post an iser patch to add this stuff to iser as well.

-- 
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] Using GM + OpenIB in the same process at the same time.

2007-01-17 Thread Roland Dreier

[adding openib-general CC]

  I have a question about using GM + OpenIB at the same time, it seems
  to be causing bad things to happen (process goes into state D) :-).
  Here is the issue:
  In Open MPI we allow striping of an MPI message across multiple
  interconnects at once. In this case I am using GM and OpenIB. This is
  using an RDMA pipeline protocol which attempts to overlap
  registration and communication (RDMA Write). In the protocol the
  target registers a chunk of the message and sends an RDMA Write
  request to the origin, the origin then registers the corresponding
  chunk of memory and initiates an RDMA Write.  Upon completion of the
  RDMA Write an RDMA FIN message is sent from the origin to the target.
  The target is allowed to have 4 RDMA Write requests outstanding at
  any time.
  As an example, lets say that the user buffer extends from address 3
  through 12200. The target begins by registering lets say address 3 -
  8000 with OpenIB, under the covers the addresses are page aligned so
  we actually register from 0 through 8191. An RDMA Write request is
  sent to the origin, note that the origin will only RDMA Write into
  addresses 3 - 8000.
  The target then begins registering address 8001 through 12200 with
  GM, again under the covers the addresses are page aligned so we
  actually register from 4096 through 12287 and send an RDMA Write
  request to the origin. Again note that the origin will only RDMA
  Write into address  8001 through 12200.
  
  The problem is that when this occurs the process goes into D state
  (uninterruptible sleep). After this occurs I am still able to use GM
  and OpenIB individually and can even attempt to use them together
  (with the result of the process again going into state D).

Finding out where the process is sleeping would probably be useful.
You can do cat /proc/pid/wchan to get a little info.

Even better would be to to echo t  /proc/sysrq-trigger and send the
complete kernel log messages that that produces (and also include the
PID that is stuck in uninterruptible sleep).

However I think it will probably be up to myricom to debug this in the
end -- my ability to figure out what's happening is very limited
without the GM sources, and I'm not that interested in debugging
someone else's proprietary software anyway.

 - 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] OFED1.1 and Fed core 6 install question

2007-01-17 Thread parks fields

When trying to install OFED1.1 on my completely updated  AMD 64bit
Fedora core 6 machine I can't get past the following error.

ERROR: The sysfsutils-devel package is required to build
libibverbs_devel RPM

I have tried a custom install and not selecting libibverbs_devel but it
to to use it anyway. Even the basic install selects it.

I have all these RPMs installed

libsysfs-2.0.0-6
sysfsutils-2.1.0-1
sysfsutils-debuginfo-2.1.0
libsysfs-devel-2.0.0-6



But no where on RPMfind or the rest of the net do I find
sysfsutils-devel for Fedora core 6  X86_64.

Even when I build sysfs from the tar ball I don't get a sysfsutils-devel

Ideas ??


thanks
parks







-- 
parks fields [EMAIL PROTECTED]
HPC-5


___
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] Reminder: OFED 1.2

2007-01-17 Thread Sasha Khapyorsky

On 13:34 Tue 16 Jan , Jeff Squyres wrote:
 FWIW, having git's for the MPI implementations was asked for on the  
 call yesterday (by Tziporet, IIRC?).  The rationale, as I understood  
 it, was threefold:
 
 1. Putting the MPI release in git provides a level of OFED-specific  
 history and version control.  This was explicitly stated on the call  
 yesterday.

Which history information we are expecting to see between bin-file-ver1
and bin-file-ver2, where files bin-file-ver* are never changed?

 2. MPI's have concrete releases to OFED just like all other ULP's,  
 especially if there is any OFED-specific packaging involved in the  
 MPI's release.  This was not stated on the call, but it makes sense  
 to me.
 
 3. Putting everything in git makes it nicely uniform for OFED to be  
 assembled.  This was not stated on the call, and I'm sure it's not a  
 requirement, but it is a little nice to be uniform when assembling  
 OFED (my $0.02).
 
 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior  
 OFED release processes,

Yes, and it was bad practice IMO. GIT and SVN are version tracking tools,
mostly usable for sources and not for compilation results. Why one
should install git if everything really needed is just to download file
from the server?

 so putting them in a git seems to parallel  
 that procedure.

Just file hosting should be perfectly enough for the all above. I don't
see any real reason to use git as non-versioned binary files storage.

Sasha

___
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] Reminder: OFED 1.2

2007-01-17 Thread Jeff Squyres

On Jan 17, 2007, at 5:02 PM, Sasha Khapyorsky wrote:

 1. Putting the MPI release in git provides a level of OFED-specific
 history and version control.  This was explicitly stated on the call
 yesterday.

 Which history information we are expecting to see between bin-file- 
 ver1
 and bin-file-ver2, where files bin-file-ver* are never changed?

I think the point is when they *do* change.

 2. MPI's have concrete releases to OFED just like all other ULP's,
 especially if there is any OFED-specific packaging involved in the
 MPI's release.  This was not stated on the call, but it makes sense
 to me.

 3. Putting everything in git makes it nicely uniform for OFED to be
 assembled.  This was not stated on the call, and I'm sure it's not a
 requirement, but it is a little nice to be uniform when assembling
 OFED (my $0.02).

 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior
 OFED release processes,

 Yes, and it was bad practice IMO. GIT and SVN are version tracking  
 tools,
 mostly usable for sources and not for compilation results. Why one
 should install git if everything really needed is just to download  
 file
 from the server?

The SRPMs are not compilation results.  Putting compilation results  
in a version tracking tool would be useless, I agree.

 so putting them in a git seems to parallel
 that procedure.

 Just file hosting should be perfectly enough for the all above. I  
 don't
 see any real reason to use git as non-versioned binary files storage.

I think the point was that you could then get a definitive set of  
files that were shipped in OFED version x.y -- you could accurately  
rebuild OFED regardless of what files are hosted on the other open  
source web sites.  A perfect example is that the MVAPICH1 package in  
OFED is prepared by Mellanox, not OSU.  So there was no web site to  
make that tarball and support files available from.  Another example  
is that open source projects may decide to no longer host older  
versions of their software -- OFA may not be able to control that.

The point here is that version control principles apply to binaries  
just as well as they apply to sources (indeed, the files we're  
talking about here are binary bundles of sources).

Just my $0.02.  :-)

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems


___
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/RFC 2.6.21] ehca: ehca_uverbs.c: refactor ehca_mmap() for better readability

2007-01-17 Thread Hoang-Nam Nguyen

Hello,
here is a patch for ehca_uverbs.c with the following changes:
- Rename mm_open/close() to ehca_mm_open/close() respectively
- Refactor ehca_mmap() into sub-functions ehca_mmap_cq/qp(),
which then call the new common sub-functions ehca_mmap_fw()
and ehca_mmap_queue() to register firmware memory block and
queue pages respectively
Roland, please note that I applied the previous patches to
your git tree for-2.6.21 before creating this patch. I also
realized a compile issue with the patch from Michael T. in
ehca_reqs.c regarding return qp pointer in ib_wc. For this
I'll send another patch.
Thanks!
Nam


Signed-off-by Hoang-Nam Nguyen [EMAIL PROTECTED]
---


 ehca_uverbs.c |  266 +++---
 1 file changed, 146 insertions(+), 120 deletions(-)


diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_uverbs.c 
infiniband_work/drivers/infiniband/hw/ehca/ehca_uverbs.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_uverbs.c 2007-01-17 
21:39:01.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_uverbs.c2007-01-17 
21:17:00.0 +0100
@@ -68,7 +68,7 @@ int ehca_dealloc_ucontext(struct ib_ucon
return 0;
 }
 
-static void mm_open(struct vm_area_struct *vma)
+static void ehca_mm_open(struct vm_area_struct *vma)
 {
u32 *count = (u32*)vma-vm_private_data;
if (!count) {
@@ -84,7 +84,7 @@ static void mm_open(struct vm_area_struc
 vma-vm_start, vma-vm_end, *count);
 }
 
-static void mm_close(struct vm_area_struct *vma)
+static void ehca_mm_close(struct vm_area_struct *vma)
 {
u32 *count = (u32*)vma-vm_private_data;
if (!count) {
@@ -98,26 +98,150 @@ static void mm_close(struct vm_area_stru
 }
 
 static struct vm_operations_struct vm_ops = {
-   .open = mm_open,
-   .close = mm_close,
+   .open = ehca_mm_open,
+   .close = ehca_mm_close,
 };
 
-static int ehca_mmap_qpages(struct vm_area_struct *vma, struct ipz_queue 
*queue)
+static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
+   u32 *mm_count)
 {
+   int ret;
+   u64 vsize, physical;
+
+   vsize = vma-vm_end - vma-vm_start;
+   if (vsize != EHCA_PAGESIZE) {
+   ehca_gen_err(invalid vsize=%lx, vma-vm_end - vma-vm_start);
+   return -EINVAL;
+   }
+
+   physical = galpas-user.fw_handle;
+   vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
+   ehca_gen_dbg(vsize=%lx physical=%lx, vsize, physical);
+   /* VM_IO | VM_RESERVED are set by remap_pfn_range() */
+   ret = remap_pfn_range(vma, vma-vm_start, physical  PAGE_SHIFT,
+ vsize, vma-vm_page_prot);
+   if (unlikely(ret)) {
+   ehca_gen_err(remap_pfn_range() failed ret=%x, ret);
+   return -ENOMEM;
+   }
+
+   vma-vm_private_data = mm_count;
+   (*mm_count)++;
+   vma-vm_ops = vm_ops;
+
+   return 0;
+}
+
+static int ehca_mmap_queue(struct vm_area_struct *vma, struct ipz_queue *queue,
+  u32 *mm_count)
+{
+   int ret;
u64 start, ofs;
struct page *page;
-   int  rc = 0;
+
+   vma-vm_flags |= VM_RESERVED;
start = vma-vm_start;
for (ofs = 0; ofs  queue-queue_length; ofs += PAGE_SIZE) {
u64 virt_addr = (u64)ipz_qeit_calc(queue, ofs);
page = virt_to_page(virt_addr);
-   rc = vm_insert_page(vma, start, page);
-   if (unlikely(rc)) {
-   ehca_gen_err(vm_insert_page() failed rc=%x, rc);
-   return rc;
+   ret = vm_insert_page(vma, start, page);
+   if (unlikely(ret)) {
+   ehca_gen_err(vm_insert_page() failed rc=%x, ret);
+   return ret;
}
start +=  PAGE_SIZE;
}
+   vma-vm_private_data = mm_count;
+   (*mm_count)++;
+   vma-vm_ops = vm_ops;
+
+   return 0;
+}
+
+static int ehca_mmap_cq(struct vm_area_struct *vma, struct ehca_cq *cq,
+   u32 rsrc_type)
+{
+   int ret;
+
+   switch (rsrc_type) {
+   case 1: /* galpa fw handle */
+   ehca_dbg(cq-ib_cq.device, cq_num=%x fw, cq-cq_number);
+   ret = ehca_mmap_fw(vma, cq-galpas, cq-mm_count_galpa);
+   if (unlikely(ret)) {
+   ehca_err(cq-ib_cq.device,
+ehca_mmap_fw() failed rc=%x cq_num=%x,
+ret, cq-cq_number);
+   return ret;
+   }
+   break;
+
+   case 2: /* cq queue_addr */
+   ehca_dbg(cq-ib_cq.device, cq_num=%x queue, cq-cq_number);
+   ret = ehca_mmap_queue(vma, cq-ipz_queue, cq-mm_count_queue);
+   if (unlikely(ret)) {
+   ehca_err(cq-ib_cq.device,
+ehca_mmap_queue() failed rc=%x

[openib-general] [PATCH] IB/core - ib_umad can cause address alignment fault on ia64

2007-01-17 Thread Ralph Campbell

IB/core - ib_umad can cause address alignment fault

In user_mad.c, the definition for struct ib_umad_packet includes
struct ib_user_mad at an odd 32-bit offset.  When ib_umad_write()
tries to assign rmpp_mad-mad_hdr.tid, there is an alignment fault on
architectures which have strict alignment for load/stores.
This patch fixes the problem by changing the offset on which
struct ib_user_mad is defined within struct ib_umad_packet.

Thanks go to John W. Marland [EMAIL PROTECTED] for finding this.

Signed-off-by: Ralph Campbell [EMAIL PROTECTED]

diff -r b1128b48dc99 drivers/infiniband/core/user_mad.c
--- a/drivers/infiniband/core/user_mad.cFri Jan 12 20:00:03 2007 +
+++ b/drivers/infiniband/core/user_mad.cWed Jan 17 14:09:37 2007 -0800
@@ -125,7 +125,7 @@ struct ib_umad_packet {
struct ib_mad_send_buf *msg;
struct ib_mad_recv_wc  *recv_wc;
struct list_head   list;
-   intlength;
+   long   length;
struct ib_user_mad mad;
 };
 



___
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] Reminder: OFED 1.2

2007-01-17 Thread Michael S. Tsirkin

  I don't really care one way or another; this was just my  
  understanding of why it was requested.
 
 


 Jeff is correct - I requested this from the reasons above.

I think all we need for OFED is just a *fixed* URL where OFED
build script can download the OFED-specific SRPM for 1.2.

If this is a problem for OSU it can be hosted at the openfabrics server.

Correct?
-- 
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] Reminder: OFED 1.2

2007-01-17 Thread Jeff Squyres

This is such a trivial matter that it really isn't worth arguing  
about.  :-)

Tell us MPI guys how you want MPI releases published to OFED and  
we'll do it.


On Jan 17, 2007, at 5:22 PM, Michael S. Tsirkin wrote:

 I don't really care one way or another; this was just my
 understanding of why it was requested.




 Jeff is correct - I requested this from the reasons above.

 I think all we need for OFED is just a *fixed* URL where OFED
 build script can download the OFED-specific SRPM for 1.2.

 If this is a problem for OSU it can be hosted at the openfabrics  
 server.

 Correct?
 -- 
 MST


-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems


___
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] Reminder: OFED 1.2

2007-01-17 Thread Sasha Khapyorsky

On 00:22 Thu 18 Jan , Michael S. Tsirkin wrote:
   I don't really care one way or another; this was just my  
   understanding of why it was requested.
  
  
 
 
  Jeff is correct - I requested this from the reasons above.
 
 I think all we need for OFED is just a *fixed* URL where OFED
 build script can download the OFED-specific SRPM for 1.2.
 
 If this is a problem for OSU it can be hosted at the openfabrics server.
 
 Correct?

Seems reasonable for me.

Sasha

___
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] Reminder: OFED 1.2

2007-01-17 Thread Sasha Khapyorsky

On 17:04 Wed 17 Jan , Jeff Squyres wrote:
 On Jan 17, 2007, at 5:02 PM, Sasha Khapyorsky wrote:
 
 1. Putting the MPI release in git provides a level of OFED-specific
 history and version control.  This was explicitly stated on the call
 yesterday.
 
 Which history information we are expecting to see between bin-file- 
 ver1
 and bin-file-ver2, where files bin-file-ver* are never changed?
 
 I think the point is when they *do* change.

But when they do change we update the version and create new binary
file - bin-file-ver2.1 .

 2. MPI's have concrete releases to OFED just like all other ULP's,
 especially if there is any OFED-specific packaging involved in the
 MPI's release.  This was not stated on the call, but it makes sense
 to me.
 
 3. Putting everything in git makes it nicely uniform for OFED to be
 assembled.  This was not stated on the call, and I'm sure it's not a
 requirement, but it is a little nice to be uniform when assembling
 OFED (my $0.02).
 
 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior
 OFED release processes,
 
 Yes, and it was bad practice IMO. GIT and SVN are version tracking  
 tools,
 mostly usable for sources and not for compilation results. Why one
 should install git if everything really needed is just to download  
 file
 from the server?
 
 The SRPMs are not compilation results. 

Right, it is source packaging results - similar meaning.

 Putting compilation results  
 in a version tracking tool would be useless, I agree.
 
 so putting them in a git seems to parallel
 that procedure.
 
 Just file hosting should be perfectly enough for the all above. I  
 don't
 see any real reason to use git as non-versioned binary files storage.
 
 I think the point was that you could then get a definitive set of  
 files that were shipped in OFED version x.y -- you could accurately  
 rebuild OFED regardless of what files are hosted on the other open  
 source web sites.

This is tracked in fetch/build scripts, and it is under version control.
External packages can be hosted (or just copyed) on the OFA site.

 A perfect example is that the MVAPICH1 package in  
 OFED is prepared by Mellanox, not OSU.  So there was no web site to  
 make that tarball and support files available from.  Another example  
 is that open source projects may decide to no longer host older  
 versions of their software -- OFA may not be able to control that.
 
 The point here is that version control principles apply to binaries  
 just as well as they apply to sources (indeed, the files we're  
 talking about here are binary bundles of sources).

Only if we are going to change such files, but I guess in our case we
are not - instead we will create new package files with new versions.

Sasha

___
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 0/6] osm: QoS policy parser

2007-01-17 Thread Sasha Khapyorsky

Hi Yevgeny,

On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote:
 Hi Hal
 
 The following series of six patches implements QoS policy file parser:
 
 1. QoS parser Lex file
 2. QoS parser Lex-generated c file
 3. QoS parser grammar (Yacc) file
 4. QoS parser Yacc-generated grammar c and h file
 5. QoS parser header file that defines parse tree data structures 
 6. Changes in makefiles and configure.in file for compiling QoS parser files

Is there any description of proposed format and functionality?

Also what about using human readable formats?

Sasha

___
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 TRIVIAL] opensm: make osm object local

2007-01-17 Thread Hal Rosenstock

On Wed, 2007-01-17 at 19:44, Sasha Khapyorsky wrote:
 This defines osm object as local variable.
 
 Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]

Thanks. Applied.

-- 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/core - ib_umad can cause address alignment fault on ia64

2007-01-17 Thread Michael S. Tsirkin

 Quoting Ralph Campbell [EMAIL PROTECTED]:
 Subject: [PATCH] IB/core - ib_umad can cause address alignment fault on ia64
 
 IB/core - ib_umad can cause address alignment fault
 
 In user_mad.c, the definition for struct ib_umad_packet includes
 struct ib_user_mad at an odd 32-bit offset.  When ib_umad_write()
 tries to assign rmpp_mad-mad_hdr.tid, there is an alignment fault on
 architectures which have strict alignment for load/stores.
 This patch fixes the problem by changing the offset on which
 struct ib_user_mad is defined within struct ib_umad_packet.
 
 Thanks go to John W. Marland [EMAIL PROTECTED] for finding this.
 
 Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
 
 diff -r b1128b48dc99 drivers/infiniband/core/user_mad.c
 --- a/drivers/infiniband/core/user_mad.c  Fri Jan 12 20:00:03 2007 +
 +++ b/drivers/infiniband/core/user_mad.c  Wed Jan 17 14:09:37 2007 -0800
 @@ -125,7 +125,7 @@ struct ib_umad_packet {
   struct ib_mad_send_buf *msg;
   struct ib_mad_recv_wc  *recv_wc;
   struct list_head   list;
 - intlength;
 + long   length;
   struct ib_user_mad mad;
  };

This does not make sense to me - do we have to replace all int fields with long
now? Looks like a compiler or makefile bug in your setup - struct fields should
be naturally aligned.

-- 
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] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]

2007-01-17 Thread Michael S. Tsirkin

 What about pure opensource - http://sourceware.org/pthreads-win32/? It
 is licensed under LGPL, I see on the net many positive reports about
 stability and usability.

I used it to do a windows port of linux complib at some point and opensm
seemed to work fine with it. What it was lacking at that point was
support for 64 bit applications, and for some reason (which is
still unclear to me) there was a strong desire to run opensm in 64 bit mode.
Seems to have been fixed now, BTW.

-- 
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] nightly osm_sim report 2007-01-18:normal completion

2007-01-17 Thread Eitan Zahavi

OSM Simulation Regression Summary
OpenSM rev = Wed_Jan_17_13:32:47_2007 c2a39a 
ibutils rev = Wed_Jan_3_11:42:12_2007 913448 
Total=410 Pass=410 Fail=0

Pass:
30 Stability IS1-16.topo
30 Pkey IS1-16.topo
30 OsmTest IS1-16.topo
30 OsmStress IS1-16.topo
30 Multicast IS1-16.topo
30 LidMgr IS1-16.topo
10 Stability IS3-loop.topo
10 Stability IS3-128.topo
10 Pkey IS3-128.topo
10 OsmTest IS3-loop.topo
10 OsmTest IS3-128.topo
10 OsmStress IS3-128.topo
10 Multicast IS3-loop.topo
10 Multicast IS3-128.topo
10 LidMgr IS3-128.topo
10 FatTree part-4-ary-3-tree.topo
10 FatTree merge-roots-reorder-4-ary-2-tree.topo
10 FatTree merge-roots-4-ary-2-tree.topo
10 FatTree merge-root-4-ary-3-tree.topo
10 FatTree merge-root-12-ary-2-tree.topo
10 FatTree merge-2-ary-4-tree.topo
10 FatTree half-4-ary-3-tree.topo
10 FatTree blend-4-ary-2-tree.topo
10 FatTree 4-ary-4-tree.topo
10 FatTree 4-ary-3-tree.topo
10 FatTree 32nodes-3lvl-is1.topo
10 FatTree 2-ary-4-tree.topo
10 FatTree 12-node-spaced.topo
10 FatTree 12-ary-2-tree.topo

Failures:

___
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

62 matches

Mail list logo