Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Greg KH 
On Thu, Apr 21, 2005 at 03:07:42PM -0500, Timur Tabi wrote:
> >*You* need to come up with a solution that looks good to *the community*
> >if you want it merged.  
> 
> True, but I'm not going to waste my time adding this support if the 
> consensus I get from the kernel developers that they don't want Linux to 
> behave this way.

I think we have been giving you that consensus from the very
beginning :)

The very fact that you tried to trot out the "enterprise" card should
have raised a huge flag...

thanks,

greg k-h
___
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] [MAD RMPP] add RMPP send support to MAD layer

2005-04-21 Thread Sean Hefty 
The following patch adds RMPP send support to the kernel MAD layer.

- NACKs are not implemented
- Spec compliant double-sided transfers are not implemented.  Request/
  reply matching works, but missing is the ACK to the ACK that
  occurs during the RMPP direction switch.
- Clients are limited to a single sge.
- Timeout values are hard-coded until such time that packet lifetimes
  magically appear.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>


Index: include/ib_verbs.h
===
--- include/ib_verbs.h  (revision 2207)
+++ include/ib_verbs.h  (working copy)
@@ -573,6 +573,7 @@
u32 remote_qpn;
u32 remote_qkey;
int timeout_ms; /* valid for MADs only */
+   int retries;/* valid for MADs only */
u16 pkey_index; /* valid for GSI only */
u8  port_num;   /* valid for DR SMPs on switch only 
*/
} ud;
Index: core/mad_rmpp.c
===
--- core/mad_rmpp.c (revision 2207)
+++ core/mad_rmpp.c (working copy)
@@ -76,20 +76,6 @@
struct ib_sge sge;
 };
 
-static struct ib_ah * create_ah_from_wc(struct ib_pd *pd, struct ib_wc *wc,
-   u8 port_num)
-{
-   struct ib_ah_attr ah_attr;
-
-   memset(&ah_attr, 0, sizeof ah_attr);
-   ah_attr.dlid = wc->slid;
-   ah_attr.sl = wc->sl;
-   ah_attr.src_path_bits = wc->dlid_path_bits;
-   ah_attr.port_num = port_num;
-
-   return ib_create_ah(pd, &ah_attr);
-}
-
 static void destroy_rmpp_recv(struct mad_rmpp_recv *rmpp_recv)
 {
atomic_dec(&rmpp_recv->refcount);
@@ -164,9 +150,10 @@
if (!rmpp_recv)
return NULL;
 
-   rmpp_recv->ah = create_ah_from_wc(agent->agent.qp->pd,
- mad_recv_wc->wc,
- agent->agent.port_num);
+   rmpp_recv->ah = ib_create_ah_from_wc(agent->agent.qp->pd,
+mad_recv_wc->wc,
+mad_recv_wc->recv_buf.grh,
+agent->agent.port_num);
if (IS_ERR(rmpp_recv->ah))
goto error;
 
@@ -291,18 +278,28 @@
kfree(msg);
 }
 
+static int data_offset(u8 mgmt_class)
+{
+   if (mgmt_class == IB_MGMT_CLASS_SUBN_ADM)
+   return offsetof(struct ib_sa_mad, data);
+   else if ((mgmt_class >= IB_MGMT_CLASS_VENDOR_RANGE2_START) &&
+(mgmt_class <= IB_MGMT_CLASS_VENDOR_RANGE2_END))
+   return offsetof(struct ib_vendor_mad, data);
+   else
+   return offsetof(struct ib_rmpp_mad, data);
+}
+
 static void format_ack(struct ib_rmpp_mad *ack,
   struct ib_rmpp_mad *data,
   struct mad_rmpp_recv *rmpp_recv)
 {
unsigned long flags;
 
-   ack->mad_hdr = data->mad_hdr;
+   memcpy(&ack->mad_hdr, &data->mad_hdr,
+  data_offset(data->mad_hdr.mgmt_class));
+
ack->mad_hdr.method ^= IB_MGMT_METHOD_RESP;
-   ack->rmpp_hdr.rmpp_version = data->rmpp_hdr.rmpp_version;
ack->rmpp_hdr.rmpp_type = IB_MGMT_RMPP_TYPE_ACK;
-   ib_set_rmpp_resptime(&ack->rmpp_hdr,
-ib_get_rmpp_resptime(&data->rmpp_hdr));
ib_set_rmpp_flags(&ack->rmpp_hdr, IB_MGMT_RMPP_FLAG_ACTIVE);
 
spin_lock_irqsave(&rmpp_recv->lock, flags);
@@ -392,12 +389,18 @@
 
 static inline int get_mad_len(struct mad_rmpp_recv *rmpp_recv)
 {
-   int hdr_size;
+   struct ib_rmpp_mad *rmpp_mad;
+   int hdr_size, data_size, pad;
 
-   /* TODO: need to check for SA MADs - requires access to SA header */
-   hdr_size = sizeof(struct ib_mad_hdr) + sizeof(struct ib_rmpp_hdr);
-   return rmpp_recv->seg_num * (sizeof(struct ib_mad) - hdr_size) +
-  hdr_size;
+   rmpp_mad = (struct ib_rmpp_mad *)rmpp_recv->cur_seg_buf->mad;
+
+   hdr_size = data_offset(rmpp_mad->mad_hdr.mgmt_class);
+   data_size = sizeof(struct ib_rmpp_mad) - hdr_size;
+   pad = be32_to_cpu(rmpp_mad->rmpp_hdr.paylen_newwin);
+   if (pad > data_size)
+   pad = 0;
+
+   return hdr_size + rmpp_recv->seg_num * data_size - pad;
 }
 
 static struct ib_mad_recv_wc * complete_rmpp(struct mad_rmpp_recv *rmpp_recv)
@@ -513,6 +516,121 @@
return mad_recv_wc;
 }
 
+static inline u64 get_seg_addr(struct ib_mad_send_wr_private *mad_send_wr)
+{
+   return mad_send_wr->sg_list[0].addr + mad_send_wr->data_offset +
+  (sizeof(struct ib_rmpp_mad) - mad_send_wr->data_offset) *
+  (mad_send_wr->seg_num - 1);
+}
+
+static int send_next_seg(struct ib_mad_send_wr_private *mad_send_wr)
+{
+   struct ib_rmpp_mad *rmpp_mad;
+   int timeout;
+
+   rmpp_mad = (struct ib_rmp

[openib-general] [PATCHv4][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Tom Duffy 
On Thu, 2005-04-21 at 16:31 -0700, Fab Tillier wrote:
> Isn't the above change backwards?  The original code was copying settings
> from listen_sk to sk, and the new code seems to be checking flags in sk to
> determine whether to set them in listen_sk.

You are so right.  My brain ain't on today or something.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(working copy)
@@ -1112,6 +1112,15 @@ error_attr:
return result;
 }
 
+/* XXX remove if/else (leave struct) once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11) )
+static struct proto sdp_proto = {
+   .name   = "sdp_sock",
+   .owner  = THIS_MODULE,
+   .obj_size   = sizeof(struct inet_sock),
+};
+#endif
+
 /*
  * sdp_conn_alloc - allocate a new socket, and init.
  */
@@ -1122,7 +1131,12 @@ struct sdp_opt *sdp_conn_alloc(int prior
int result;
 
sk = sk_alloc(dev_root_s.proto, priority, 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
  sizeof(struct inet_sock), dev_root_s.sock_cache);
+#else
+ &sdp_proto, 1);
+#endif
if (!sk) {
sdp_dbg_warn(NULL, "socket alloc error for protocol. <%d:%d>",
 dev_root_s.proto, priority);
@@ -1966,6 +1980,8 @@ int sdp_conn_table_init(int proto_family
goto error_conn;
}
 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
 dev_root_s.sock_cache = kmem_cache_create("sdp_sock",
  sizeof(struct inet_sock), 
  0, SLAB_HWCACHE_ALIGN,
@@ -1975,6 +1991,13 @@ int sdp_conn_table_init(int proto_family
result = -ENOMEM;
goto error_sock;
 }
+#else
+   if (proto_register(&sdp_proto, 1) != 0) {
+   sdp_warn("Failed to register sdp proto.");
+   result = -ENOMEM;
+   goto error_sock;
+   }
+#endif
 
/*
 * start listening
@@ -2002,7 +2025,12 @@ int sdp_conn_table_init(int proto_family
 error_listen:
(void)ib_destroy_cm_id(dev_root_s.listen_id);
 error_cm_id:
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
 error_sock:
kmem_cache_destroy(dev_root_s.conn_cache);
 error_conn:
@@ -2049,10 +2077,15 @@ int sdp_conn_table_clear(void)
 * delete conn cache
 */
kmem_cache_destroy(dev_root_s.conn_cache);
+/* Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
/*
 * delete sock cache
 */
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
/*
 * stop listening
 */
Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(working copy)
@@ -356,13 +356,23 @@ static int sdp_cm_listen_lookup(struct s
 */
sk->sk_lingertime   = listen_sk->sk_lingertime;
sk->sk_rcvlowat = listen_sk->sk_rcvlowat;
+/* XXX Remove once 2.6.12 is released */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
sk->sk_debug= listen_sk->sk_debug;
sk->sk_localroute   = listen_sk->sk_localroute;
+   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
+#else
+   if (sock_flag(listen_sk, SOCK_DBG))
+   sock_set_flag(sk, SOCK_DBG);
+   if (sock_flag(listen_sk, SOCK_LOCALROUTE))
+   sock_set_flag(sk, SOCK_LOCALROUTE);
+   if (sock_flag(listen_sk, SOCK_RCVTSTAMP))
+   sock_set_flag(sk, SOCK_RCVTSTAMP);
+#endif
sk->sk_sndbuf   = listen_sk->sk_sndbuf;
sk->sk_rcvbuf   = listen_sk->sk_rcvbuf;
sk->sk_no_check = listen_sk->sk_no_check;
sk->sk_priority = listen_sk->sk_priority;
-   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
sk->sk_rcvtimeo = listen_sk->sk_rcvtimeo;
sk->sk_sndtimeo = listen_sk->sk_sndtimeo;
sk->sk_reuse= listen_sk->sk_reuse;
Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
(revision 2207)
+++ linux-2.6.12-rc3-openib/driv

[openib-general] [PATCHv3][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Tom Duffy 
On Thu, 2005-04-21 at 16:17 -0700, Libor Michalek wrote:
>   Is this a trick question? :) Because it's not a bool but an integer,
> which use to be a bool in the 2.4 kernel days. Here's the relevant
> code snip from net/core/sock.c:
> 
>   if (zero_it) {
>   memset(sk, 0,
>  zero_it == 1 ? sizeof(struct sock) : zero_it);
>   sk->sk_family = family;
>   sock_lock_init(sk);
>   }

Sorry, I was looking at the new code where it is (used as) a bool again.
In fact, I fucked up and on my v2 patch, the *new* call to sk_alloc
should just be 1.  Here is v3.

Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(working copy)
@@ -1112,6 +1112,15 @@ error_attr:
return result;
 }
 
+/* XXX remove if/else (leave struct) once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11) )
+static struct proto sdp_proto = {
+   .name   = "sdp_sock",
+   .owner  = THIS_MODULE,
+   .obj_size   = sizeof(struct inet_sock),
+};
+#endif
+
 /*
  * sdp_conn_alloc - allocate a new socket, and init.
  */
@@ -1122,7 +1131,12 @@ struct sdp_opt *sdp_conn_alloc(int prior
int result;
 
sk = sk_alloc(dev_root_s.proto, priority, 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
  sizeof(struct inet_sock), dev_root_s.sock_cache);
+#else
+ &sdp_proto, 1);
+#endif
if (!sk) {
sdp_dbg_warn(NULL, "socket alloc error for protocol. <%d:%d>",
 dev_root_s.proto, priority);
@@ -1966,6 +1980,8 @@ int sdp_conn_table_init(int proto_family
goto error_conn;
}
 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
 dev_root_s.sock_cache = kmem_cache_create("sdp_sock",
  sizeof(struct inet_sock), 
  0, SLAB_HWCACHE_ALIGN,
@@ -1975,6 +1991,13 @@ int sdp_conn_table_init(int proto_family
result = -ENOMEM;
goto error_sock;
 }
+#else
+   if (proto_register(&sdp_proto, 1) != 0) {
+   sdp_warn("Failed to register sdp proto.");
+   result = -ENOMEM;
+   goto error_sock;
+   }
+#endif
 
/*
 * start listening
@@ -2002,7 +2025,12 @@ int sdp_conn_table_init(int proto_family
 error_listen:
(void)ib_destroy_cm_id(dev_root_s.listen_id);
 error_cm_id:
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
 error_sock:
kmem_cache_destroy(dev_root_s.conn_cache);
 error_conn:
@@ -2049,10 +2077,15 @@ int sdp_conn_table_clear(void)
 * delete conn cache
 */
kmem_cache_destroy(dev_root_s.conn_cache);
+/* Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
/*
 * delete sock cache
 */
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
/*
 * stop listening
 */
Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(working copy)
@@ -356,13 +356,23 @@ static int sdp_cm_listen_lookup(struct s
 */
sk->sk_lingertime   = listen_sk->sk_lingertime;
sk->sk_rcvlowat = listen_sk->sk_rcvlowat;
+/* XXX Remove once 2.6.12 is released */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
sk->sk_debug= listen_sk->sk_debug;
sk->sk_localroute   = listen_sk->sk_localroute;
+   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
+#else
+   if (sock_flag(sk, SOCK_DBG))
+   sock_set_flag(listen_sk, SOCK_DBG);
+   if (sock_flag(sk, SOCK_LOCALROUTE))
+   sock_set_flag(listen_sk, SOCK_LOCALROUTE);
+   if (sock_flag(sk, SOCK_RCVTSTAMP))
+   sock_set_flag(listen_sk, SOCK_RCVTSTAMP);
+#endif
sk->sk_sndbuf   = listen_sk->sk_sndbuf;
sk->sk_rcvbuf   = listen_sk->sk_rcvbuf;
sk->sk_no_check = listen_sk->sk_no_check;
sk->sk_priority = listen_sk->sk_priority;
-   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
sk->sk_rcvtimeo = listen_sk->sk_rcvtimeo;
sk->sk_sndtimeo = listen_sk->sk_sndtimeo;

RE: [openib-general] [PATCHv2][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Fab Tillier 
> From: Tom Duffy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 21, 2005 4:27 PM
> 
> Ok, this patch now builds without warning on 2.6.11 and 2.6.12-rc3.
> 
> Libor, what do you think?
> 
> Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
> ===
> --- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
>   (revision 2207)
> +++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
(working
> copy)
> @@ -356,13 +356,23 @@ static int sdp_cm_listen_lookup(struct s
>*/
>   sk->sk_lingertime   = listen_sk->sk_lingertime;
>   sk->sk_rcvlowat = listen_sk->sk_rcvlowat;
> +/* XXX Remove once 2.6.12 is released */
> +#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
>   sk->sk_debug= listen_sk->sk_debug;
>   sk->sk_localroute   = listen_sk->sk_localroute;
> + sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
> +#else
> + if (sock_flag(sk, SOCK_DBG))
> + sock_set_flag(listen_sk, SOCK_DBG);
> + if (sock_flag(sk, SOCK_LOCALROUTE))
> + sock_set_flag(listen_sk, SOCK_LOCALROUTE);
> + if (sock_flag(sk, SOCK_RCVTSTAMP))
> + sock_set_flag(listen_sk, SOCK_RCVTSTAMP);
> +#endif

Isn't the above change backwards?  The original code was copying settings
from listen_sk to sk, and the new code seems to be checking flags in sk to
determine whether to set them in listen_sk.

- Fab

___
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] [PATCHv2][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Tom Duffy 
On Thu, 2005-04-21 at 15:36 -0700, Roland Dreier wrote:
> (I don't have time track down what goes in struct proto right now, so
> I'm not posting a real patch)

Ok, this patch now builds without warning on 2.6.11 and 2.6.12-rc3.

Libor, what do you think?

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_conn.c   
(working copy)
@@ -1112,6 +1112,15 @@ error_attr:
return result;
 }
 
+/* XXX remove if/else (leave struct) once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11) )
+static struct proto sdp_proto = {
+   .name   = "sdp_sock",
+   .owner  = THIS_MODULE,
+   .obj_size   = sizeof(struct inet_sock),
+};
+#endif
+
 /*
  * sdp_conn_alloc - allocate a new socket, and init.
  */
@@ -1122,7 +1131,12 @@ struct sdp_opt *sdp_conn_alloc(int prior
int result;
 
sk = sk_alloc(dev_root_s.proto, priority, 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
  sizeof(struct inet_sock), dev_root_s.sock_cache);
+#else
+ &sdp_proto, sizeof(struct inet_sock));
+#endif
if (!sk) {
sdp_dbg_warn(NULL, "socket alloc error for protocol. <%d:%d>",
 dev_root_s.proto, priority);
@@ -1966,6 +1980,8 @@ int sdp_conn_table_init(int proto_family
goto error_conn;
}
 
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
 dev_root_s.sock_cache = kmem_cache_create("sdp_sock",
  sizeof(struct inet_sock), 
  0, SLAB_HWCACHE_ALIGN,
@@ -1975,6 +1991,13 @@ int sdp_conn_table_init(int proto_family
result = -ENOMEM;
goto error_sock;
 }
+#else
+   if (proto_register(&sdp_proto, 1) != 0) {
+   sdp_warn("Failed to register sdp proto.");
+   result = -ENOMEM;
+   goto error_sock;
+   }
+#endif
 
/*
 * start listening
@@ -2002,7 +2025,12 @@ int sdp_conn_table_init(int proto_family
 error_listen:
(void)ib_destroy_cm_id(dev_root_s.listen_id);
 error_cm_id:
+/* XXX Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
 error_sock:
kmem_cache_destroy(dev_root_s.conn_cache);
 error_conn:
@@ -2049,10 +2077,15 @@ int sdp_conn_table_clear(void)
 * delete conn cache
 */
kmem_cache_destroy(dev_root_s.conn_cache);
+/* Remove once 2.6.12 is out */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
/*
 * delete sock cache
 */
kmem_cache_destroy(dev_root_s.sock_cache);
+#else
+   proto_unregister(&sdp_proto);
+#endif
/*
 * stop listening
 */
Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(working copy)
@@ -356,13 +356,23 @@ static int sdp_cm_listen_lookup(struct s
 */
sk->sk_lingertime   = listen_sk->sk_lingertime;
sk->sk_rcvlowat = listen_sk->sk_rcvlowat;
+/* XXX Remove once 2.6.12 is released */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
sk->sk_debug= listen_sk->sk_debug;
sk->sk_localroute   = listen_sk->sk_localroute;
+   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
+#else
+   if (sock_flag(sk, SOCK_DBG))
+   sock_set_flag(listen_sk, SOCK_DBG);
+   if (sock_flag(sk, SOCK_LOCALROUTE))
+   sock_set_flag(listen_sk, SOCK_LOCALROUTE);
+   if (sock_flag(sk, SOCK_RCVTSTAMP))
+   sock_set_flag(listen_sk, SOCK_RCVTSTAMP);
+#endif
sk->sk_sndbuf   = listen_sk->sk_sndbuf;
sk->sk_rcvbuf   = listen_sk->sk_rcvbuf;
sk->sk_no_check = listen_sk->sk_no_check;
sk->sk_priority = listen_sk->sk_priority;
-   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
sk->sk_rcvtimeo = listen_sk->sk_rcvtimeo;
sk->sk_sndtimeo = listen_sk->sk_sndtimeo;
sk->sk_reuse= listen_sk->sk_reuse;
Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_dev.h
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_dev.h

Re: [openib-general] [PATCH][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Libor Michalek 
On Thu, Apr 21, 2005 at 03:52:43PM -0700, Tom Duffy wrote:
> On Thu, 2005-04-21 at 15:36 -0700, Roland Dreier wrote:
> > Is this really the only change required?  It seems that the socket
> > allocation function changed too -- 2.6.11 has
> > 
> > extern struct sock *sk_alloc(int family, int priority, int 
> > zero_it,
> >  kmem_cache_t *slab);
> > 
> > while my up-to-date Linus tree has
> > 
> > extern struct sock  *sk_alloc(int family, int priority,
> >   struct proto *prot, int 
> > zero_it);
> > 
> > so I think sdp_conn.c at least needs some fixing up.
> 
> Oh, you are right, I missed the compile warning, but I see it now.
> 
> Why does the SDP code pass in sizeof(struct inet_sock) for the zero_it
> bool?

  Is this a trick question? :) Because it's not a bool but an integer,
which use to be a bool in the 2.4 kernel days. Here's the relevant
code snip from net/core/sock.c:

if (zero_it) {
memset(sk, 0,
   zero_it == 1 ? sizeof(struct sock) : zero_it);
sk->sk_family = family;
sock_lock_init(sk);
}


-Libor

___
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][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Tom Duffy 
On Thu, 2005-04-21 at 15:36 -0700, Roland Dreier wrote:
> Is this really the only change required?  It seems that the socket
> allocation function changed too -- 2.6.11 has
> 
>   extern struct sock *sk_alloc(int family, int priority, int 
> zero_it,
>kmem_cache_t *slab);
> 
> while my up-to-date Linus tree has
> 
>   extern struct sock  *sk_alloc(int family, int priority,
> struct proto *prot, int 
> zero_it);
> 
> so I think sdp_conn.c at least needs some fixing up.

Oh, you are right, I missed the compile warning, but I see it now.

Why does the SDP code pass in sizeof(struct inet_sock) for the zero_it
bool?

-tduffy


signature.asc
Description: This is a digitally signed message part
___
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][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Roland Dreier 
Tom> The sock structure was changed in 2.6.12-rc? and SDP no
Tom> longer compiles against it.  This patch allows SDP to build
Tom> with either 2.6.11 or 2.6.12-rc3 as we must preserve building
Tom> on current stable tree.

Is this really the only change required?  It seems that the socket
allocation function changed too -- 2.6.11 has

extern struct sock *sk_alloc(int family, int priority, int 
zero_it,
 kmem_cache_t *slab);

while my up-to-date Linus tree has

extern struct sock  *sk_alloc(int family, int priority,
  struct proto *prot, int 
zero_it);

so I think sdp_conn.c at least needs some fixing up.

(I don't have time track down what goes in struct proto right now, so
I'm not posting a real patch)

 - 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] [PATCH][SDP] Allow SDP to compile on 2.6.12-rc3

2005-04-21 Thread Tom Duffy 
The sock structure was changed in 2.6.12-rc? and SDP no longer compiles
against it.  This patch allows SDP to build with either 2.6.11 or
2.6.12-rc3 as we must preserve building on current stable tree.

Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>

Index: linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c
===
--- linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(revision 2207)
+++ linux-2.6.12-rc3-openib/drivers/infiniband/ulp/sdp/sdp_pass.c   
(working copy)
@@ -356,13 +356,23 @@ static int sdp_cm_listen_lookup(struct s
 */
sk->sk_lingertime   = listen_sk->sk_lingertime;
sk->sk_rcvlowat = listen_sk->sk_rcvlowat;
+/* XXX Remove once 2.6.12 is released */
+#if ( LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11) )
sk->sk_debug= listen_sk->sk_debug;
sk->sk_localroute   = listen_sk->sk_localroute;
+   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
+#else
+   if (sock_flag(sk, SOCK_DBG))
+   sock_set_flag(listen_sk, SOCK_DBG);
+   if (sock_flag(sk, SOCK_LOCALROUTE))
+   sock_set_flag(listen_sk, SOCK_LOCALROUTE);
+   if (sock_flag(sk, SOCK_RCVTSTAMP))
+   sock_set_flag(listen_sk, SOCK_RCVTSTAMP);
+#endif
sk->sk_sndbuf   = listen_sk->sk_sndbuf;
sk->sk_rcvbuf   = listen_sk->sk_rcvbuf;
sk->sk_no_check = listen_sk->sk_no_check;
sk->sk_priority = listen_sk->sk_priority;
-   sk->sk_rcvtstamp= listen_sk->sk_rcvtstamp;
sk->sk_rcvtimeo = listen_sk->sk_rcvtimeo;
sk->sk_sndtimeo = listen_sk->sk_sndtimeo;
sk->sk_reuse= listen_sk->sk_reuse;

___
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] Rates fixed wont last long

2005-04-21 Thread Dino Ouellette 

Hello,

 We tried contacting you awhile ago about your low interest morta(ge rate.

 You have qualified for the lowest rate in years...

 You could get over $380,000 for as little as $500 a month!

 Ba(d credit? Doesn't matter, low rates are fixed no matter what!

 
 To get a free, no obli,gation consultation click below:

 http://www.cra3y.com/sign.asp



 Best Regards,

 Lisa Davenport
 
 to be remov(ed:http://www.cra3y.com/gone.asp

 this process takes one week, so please be patient. we do our 
 best to take your email/s off but you have to fill out a rem/ove
 or else you will continue to recieve email/s.
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Arjan van de Ven 
On Thu, 2005-04-21 at 13:25 -0700, Chris Wright wrote:
> * Timur Tabi ([EMAIL PROTECTED]) wrote:
> > It works with every kernel I've tried.  I'm sure there are plenty of kernel 
> > configuration options that will break our driver.  But as long as all the 
> > distros our customers use work, as well as reasonably-configured custom 
> > kernels, we're happy.
> > 
> 
> Hey, if you're happy (and, as you said, you don't intend to merge that
> bit), I'm happy ;-)


yeah... drivers giving unprivileged processes more privs belong on
bugtraq though, not in the core kernel :)


___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Chris Wright 
* Timur Tabi ([EMAIL PROTECTED]) wrote:
> It works with every kernel I've tried.  I'm sure there are plenty of kernel 
> configuration options that will break our driver.  But as long as all the 
> distros our customers use work, as well as reasonably-configured custom 
> kernels, we're happy.
> 

Hey, if you're happy (and, as you said, you don't intend to merge that
bit), I'm happy ;-)

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Timur Tabi 
Chris Wright wrote:
FYI, that will not work on all 2.6 kernels.  Specifically anything that's
not using capabilities.
It works with every kernel I've tried.  I'm sure there are plenty of kernel configuration 
options that will break our driver.  But as long as all the distros our customers use 
work, as well as reasonably-configured custom kernels, we're happy.

--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
 -- Ed Smylie, NASA engineer for Apollo 13
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Chris Wright 
* Timur Tabi ([EMAIL PROTECTED]) wrote:
> Andy Isaacson wrote:
> >Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
> >pages?  Or are you doing something more nasty?
> 
> A little more nasty.  I raise RLIMIT_MEMLOCK in the driver to "unlimited" 
> and also set cap_raise(IPC_LOCK).  I do this because I need to support all 
> 2.4 and 2.6 kernel versions with the same driver, but only 2.6.10 and later 
> have any support for non-root mlock().

FYI, that will not work on all 2.6 kernels.  Specifically anything that's
not using capabilities.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Timur Tabi 
Andy Isaacson wrote:
I'm familiar with MPI 1.0 and 2.0, but I haven't been following the
development of modern messaging APIs, so I might not make sense here...
Assuming that the app calls into the library on a fairly regular basis,
Not really.  The whole point is to have the adapter DMA the data directly from memory to 
the network.  That's why it's called RDMA - remote DMA.

Therefore, cluster admins are going to do their
darndest to avoid this behavior, so we might as well just kill the job
and make it explicit.
Yes, and if it turns out that the same MPI application dies on Linux but not on Solaris 
because Linux doesn't really care if the memory stays pinned, then we're going to see a 
lot of MPI customers transitioning away from Linux.

*You* need to come up with a solution that looks good to *the community*
if you want it merged.  
True, but I'm not going to waste my time adding this support if the consensus I get from 
the kernel developers that they don't want Linux to behave this way.

Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
pages?  Or are you doing something more nasty?
A little more nasty.  I raise RLIMIT_MEMLOCK in the driver to "unlimited" and also set 
cap_raise(IPC_LOCK).  I do this because I need to support all 2.4 and 2.6 kernel versions 
with the same driver, but only 2.6.10 and later have any support for non-root mlock().

If and when our driver is submitted to the official kernel, that nastiness will be removed 
of course.

--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
 -- Ed Smylie, NASA engineer for Apollo 13
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Andy Isaacson 
On Thu, Apr 21, 2005 at 01:39:35PM -0500, Timur Tabi wrote:
> Andy Isaacson wrote:
> >If you take the hardline position that "the app is the only thing that
> >matters", your code is unlikely to get merged.  Linux is a
> >general-purpose OS.
> 
> The problem is that our driver and library implement an API that we don't 
> fully control. The API states that the application allocates the memory and 
> tells the library to register it.  The app then goes on its merry way until 
> it's done, at which point it tells the library to deregister the memory.  
> Neither the app nor the API has any provision for the app to be notified 
> that the memory is no longer pinned and therefore can't be trusted. That 
> would be considered a critical failure from the app's perspective, so the 
> kernel would be doing it a favor by killing the process.

I'm familiar with MPI 1.0 and 2.0, but I haven't been following the
development of modern messaging APIs, so I might not make sense here...

Assuming that the app calls into the library on a fairly regular basis,
you could implement a fast-path/slow-path scheme where the library
normally operates in go-fast mode, but if a "unregister" event has
occurred, the library falls back to a less performant mode.

But now having written that I'm thinking that it's not worth the bother
- if you've got a 512P MPP job, it's basically equivalent to job death
for one of the nodes to go away in this manner -- even if the process is
still running on the node, the fact that you took a giant performance
hiccup is unacceptable.  Therefore, cluster admins are going to do their
darndest to avoid this behavior, so we might as well just kill the job
and make it explicit.

> >You might want to consider what happens with your communication system
> >in a machine running power-saving modes (in the limit, suspend-to-disk).
> >Of course most machines with Infiniband adapters aren't running swsusp,
> >but it's not inconceivable that blade servers might sleep to lower power
> >and cooling costs.
> 
> Any application that registers memory, will in all likelihood be running at 
> 100% CPU non-stop.  The computer is not going to be doing anything else but 
> whatever that app is trying to do.  The application could conceiveable 
> register gigabytes of RAM, and if even a single page becomes unpinned, the 
> whole thing is worthless.  The application cannot do anything meaningful if 
> it gets a message saying that some of the memory has become unpinned and 
> should not be used.
> 
> So the real question is: how important is it to the kernel developers that 
> Linux support these kinds of enterprise-class applications?

While I understand your arguments, this kind of rhetoric is more likely
to harden ears than to convince people you're right.  I refer you to the
"Live Patching Function" thread.

*You* need to come up with a solution that looks good to *the community*
if you want it merged.  In the long run, this process is likely to
result in *your* systems working better than if you had just gone off
and done your thing.  If you have to do something that "tastes bad" to
the average l-k hacker, *justify* it by addressing the alternatives and
explaining why your solution is the right one.

I'm leaning towards agreeing that mlock()-alicious code is the right way
to solve this problem, and it's not clear to me what the benefit of
adding a new VM_REGISTERED flag would be.

Do you guys simply raise RLIMIT_MEMLOCK to allow apps to lock their
pages?  Or are you doing something more nasty?

(Oh, I see that Libor has contributed to the other branch of this
thread... off to read...)

-andy
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Timur Tabi 
Andy Isaacson wrote:
If you take the hardline position that "the app is the only thing that
matters", your code is unlikely to get merged.  Linux is a
general-purpose OS.
The problem is that our driver and library implement an API that we don't fully control. 
The API states that the application allocates the memory and tells the library to register 
it.  The app then goes on its merry way until it's done, at which point it tells the 
library to deregister the memory.  Neither the app nor the API has any provision for the 
app to be notified that the memory is no longer pinned and therefore can't be trusted. 
That would be considered a critical failure from the app's perspective, so the kernel 
would be doing it a favor by killing the process.

You might want to consider what happens with your communication system
in a machine running power-saving modes (in the limit, suspend-to-disk).
Of course most machines with Infiniband adapters aren't running swsusp,
but it's not inconceivable that blade servers might sleep to lower power
and cooling costs.
Any application that registers memory, will in all likelihood be running at 100% CPU 
non-stop.  The computer is not going to be doing anything else but whatever that app is 
trying to do.  The application could conceiveable register gigabytes of RAM, and if even a 
single page becomes unpinned, the whole thing is worthless.  The application cannot do 
anything meaningful if it gets a message saying that some of the memory has become 
unpinned and should not be used.

So the real question is: how important is it to the kernel developers that Linux support 
these kinds of enterprise-class applications?

--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
 -- Ed Smylie, NASA engineer for Apollo 13
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [Fwd: rpms/udev/devel pam_console.dev, 1.9,1.10 udev.rules, 1.23, 1.24 udev.spec, 1.82, 1.83]

2005-04-21 Thread Roland Dreier 
Bob> Do you know what the time frame is ? i.e., how long till it ships ?

http://fedora.redhat.com/participate/schedule/

Bob> Roland, what were your thoughts on when we would be ready to
Bob> submit the user mode support upstream ?

I hope to be able to send the patches upstream soon after 2.6.12 is
released.  2.6.12-rc3 just came out so I would hope that the final
release will be in about a month or so.

 - 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] *****SPAM***** $B!zHkL)>pJs!z!!!JK\?M5v2D$"$j!K(B

2005-04-21 Thread info 
Spam detection software, running on the system "openib.ca.sandia.gov", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or block
similar future email.  If you have any questions, see
[EMAIL PROTECTED] for details.

Content preview:  $B8x3+>pJs!*(B
  [EMAIL PROTECTED](B
  $B!cD>%a(B,$BD>EE8r49$b;W$$$N$^$^!d(B
  $B!!(Bhttp://www.getluck2.net/?5001
  $B%K%C%/%M!<%`!'[EMAIL PROTECTED](B $BG/Np!'!!#3#0BeA0H>(B
  $B7l1U7?!'!!#B7?(B $B7k:'!'!!L$:'(B $B?&6H!'!!$=$NB>(B
  $B%k%C%/%9!'!!Fb=o(B $B%9%?%$%k!'!!Fb=o(B $B#HEY!'!!"!"!"!"!(B
  
$B#P#R!'!!:rG/N%:'$7$A$c$$$^$7$?!#N%:'$b:G6a$G$ODA$7$/$J$$$h$M(B(?)$B$C$F(B
  $B0V$a$?$j$J$s$+$7$A$c$C$F!&!&!&!#(B
  $B0l?M$K$J$C$?$i0l?M$K$J$C$?$G7k9=--- Begin Message ---

$B8x3+>pJs!*(B
[EMAIL PROTECTED](B
 $B!cD>%a(B,$BD>EE8r49$b;W$$$N$^$^!d(B
$B!!(Bhttp://www.getluck2.net/?5001


$B%K%C%/%M!<%`!'[EMAIL PROTECTED](B
$BG/Np!'!!#3#0BeA0H>(B
$B7l1U7?!'!!#B7?(B
$B7k:'!'!!L$:'(B
$B?&6H!'!!$=$NB>(B
$B%k%C%/%9!'!!Fb=o(B
$B%9%?%$%k!'!!Fb=o(B
$B#HEY!'!!"!"!"!"!(B
$B#P#R!'!!:rG/N%:'$7$A$c$$$^$7$?!#N%:'$b:G6a$G$ODA$7$/$J$$$h$M(B(?)$B$C$F(B
$B0V$a$?$j$J$s$+$7$A$c$C$F!&!&!&!#(B
$B0l?M$K$J$C$?$i0l?M$K$J$C$?$G7k9=!d(B
$B!!(Bhttp://www.getluck2.net/?5001


$B%K%C%/%M!<%`!'[EMAIL PROTECTED](B
$BG/Np!'!!#2#0Be8eH>(B
$B7l1U7?!'!!#A#B7?(B
$B7k:'!'!!L$:'(B
$B?&6H!'!!#O#L(B
$B%k%C%/%9!'!!!z!z!z(B
$B%9%?%$%k!'!!!z!z!z(B
$B#HEY!'!!Fb=o(B
$B#P#R!'[EMAIL PROTECTED];k$GC5$7$F$^$9!#(B
$B%^%8%a$KIU$-2q$&$N$b$1$I!"[EMAIL PROTECTED]&!&!&$C$F(B
$B$$$&$N$,K\2;$G$9!#F1$89M$([EMAIL PROTECTED]&!&!&(B


$B!c=i?4<[EMAIL PROTECTED]:n!d(B
$B!!(Bhttp://www.getluck2.net/?5001





$B"($?$/[EMAIL PROTECTED](B
$B!!=gHV$r/!9$*BT$A2<$5$$!#(B




































$B(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B
$B(--y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y-y(-(B
$B(--y(Bhttp://night.loves-tokyo.com/index.htm$B!!(-(B
$B(--y2r6X=w;[EMAIL PROTECTED];%l%VG($l>lEpD0!!(-(B
$B(--y7HBS$+$i$b(BOK $B!*!*!y0B?4(BFreeDial$B!y!!(B $B(-(B
$B(--y(Bhttp://voice.loves-tokyo.com/   $B(-(B
$B(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B
--- End Message ---
___
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] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

2005-04-21 Thread Andy Isaacson 
On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote:
> Troy Benjegerdes wrote:
> >Someone (aka Tospin, infinicon, and Amasso) should probably post a patch
> >adding '#define VM_REGISTERD 0x0100', and some extensions to
> >something like 'madvise' to set pages to be registered.
> >
> >My preference is said patch will also allow a way for the kernel to
> >reclaim registered memory from an application under memory pressure.
> 
> I don't know if VM_REGISTERED is a good idea or not, but it should be 
> absolutely impossible for the kernel to reclaim "registered" (aka pinned) 
> memory, no matter what. For RDMA services (such as Infiniband, iWARP, etc), 
> it's normal for non-root processes to pin hundreds of megabytes of memory, 
> and that memory better be locked to those physical pages until the 
> application deregisters them.

If you take the hardline position that "the app is the only thing that
matters", your code is unlikely to get merged.  Linux is a
general-purpose OS.

I don't think that Troy was suggesting the kernel should deregister
memory without notifying the application.  Personally, I envision
something like the NetBSD Scheduler Activations (SA) work, where the
kernel can notify the app of changes to its state in a very efficient
manner.  (According to the NetBSD design whitepaper, the kernel does an
upcall whenever the multithreaded app gains or loses a CPU!)

In a Linux context, I doubt that fullblown SA is necessary or
appropriate.  Rather, I'd suggest two new signals, SIGMEMLOW and
SIGMEMCRIT.  The userland comms library registers handlers for both.
When the kernel decides that it needs to reclaim some memory from the
app, it sends SIGMEMLOW.  The comms library then has the responsibility
to un-reserve some memory in an orderly fashion.  If a reasonable [1]
time has expired since SIGMEMLOW and the kernel is still hungry, the
kernel sends SIGMEMCRIT.  At this point, the comms lib *must* unregister
some memory [2] even if it has to drop state to do so; if it returns
from the signal handler without having unregistered the memory, the
kernel will SIGKILL.

[1] Part of the interface spec should cover the expectation as to how
long the library is allowed to take; I'd guess that 2 timeslices
should suffice.
[2] Is there a way for the kernel to pass down to userspace how many
pages it wants, maybe in the sigcontext?

> If kernel really thinks it needs to unpin those pages, then at the very 
> least it should kill the process, and the syslog better have a very clear 
> message indicating why.  That way, the application doesn't continue 
> thinking that everything's still going to work.  If those pages become 
> unpinned, the applications are going to experience serious data corruption.

You might want to consider what happens with your communication system
in a machine running power-saving modes (in the limit, suspend-to-disk).
Of course most machines with Infiniband adapters aren't running swsusp,
but it's not inconceivable that blade servers might sleep to lower power
and cooling costs.

-andy
___
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] [MAD] fix race completing request MAD with timeout/cancel

2005-04-21 Thread Sean Hefty 
This patch should fix an issue processing a sent MAD after it has timed
out or been canceled.  The race occurs when a response MAD matches with
the sent request.  The request could time out or be canceled after the
response MAD matches with the request, but before the request completion
can be processed.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>


Index: core/mad.c
===
--- core/mad.c  (revision 2203)
+++ core/mad.c  (working copy)
@@ -342,6 +342,7 @@
spin_lock_init(&mad_agent_priv->lock);
INIT_LIST_HEAD(&mad_agent_priv->send_list);
INIT_LIST_HEAD(&mad_agent_priv->wait_list);
+   INIT_LIST_HEAD(&mad_agent_priv->done_list);
INIT_LIST_HEAD(&mad_agent_priv->rmpp_list);
INIT_WORK(&mad_agent_priv->timed_work, timeout_sends, mad_agent_priv);
INIT_LIST_HEAD(&mad_agent_priv->local_list);
@@ -1591,6 +1592,16 @@
return NULL;
 }
 
+static void ib_mark_req_done(struct ib_mad_send_wr_private *mad_send_wr)
+{
+   mad_send_wr->timeout = 0;
+   if (mad_send_wr->refcount == 1) {
+   list_del(&mad_send_wr->agent_list);
+   list_add_tail(&mad_send_wr->agent_list,
+ &mad_send_wr->mad_agent_priv->done_list);
+   }
+}
+
 static void ib_mad_complete_recv(struct ib_mad_agent_private *mad_agent_priv,
 struct ib_mad_recv_wc *mad_recv_wc)
 {
@@ -1619,8 +1630,7 @@
wake_up(&mad_agent_priv->wait);
return;
}
-   /* Timeout = 0 means that we won't wait for a response */
-   mad_send_wr->timeout = 0;
+   ib_mark_req_done(mad_send_wr);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
 
/* Defined behavior is to complete response before request */
Index: core/mad_priv.h
===
--- core/mad_priv.h (revision 2202)
+++ core/mad_priv.h (working copy)
@@ -92,6 +92,7 @@
spinlock_t lock;
struct list_head send_list;
struct list_head wait_list;
+   struct list_head done_list;
struct work_struct timed_work;
unsigned long timeout;
struct list_head local_list;
___
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] MAD/RMPP test program

2005-04-21 Thread Sean Hefty 
For those interested (likely a few developers only), I've checked in a 
kernel test program that I used to stress the MAD/RMPP code.

gen2/utils/src/linux-kernel/infiniband/util/grmpp
- 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] [Fwd: rpms/udev/devel pam_console.dev, 1.9, 1.10 udev.rules, 1.23, 1.24 udev.spec, 1.82, 1.83]

2005-04-21 Thread Bob Woodruff 

>Looks like Fedora Core 4 will support IB out of the box.  They have the
>kernel modules, udev support, glibc-headers.  Is there anything else
>that would be nice to get right before 4 ships?

>-tduffy

Cool.

Do you know what the time frame is ? i.e., how long till it ships ?

It would be nice to get the user-mode verbs support in, but 
I think that it may need some more testing and I don't think
the user-mode kernel module has been submitted upstream yet. 

Roland, what were your thoughts on when we would be ready to submit
the user mode support upstream ?

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] [Fwd: rpms/udev/devel pam_console.dev, 1.9, 1.10 udev.rules, 1.23, 1.24 udev.spec, 1.82, 1.83]

2005-04-21 Thread Tom Duffy 
Looks like Fedora Core 4 will support IB out of the box.  They have the
kernel modules, udev support, glibc-headers.  Is there anything else
that would be nice to get right before 4 ships?

-tduffy
--- Begin Message ---
Update of /cvs/dist/rpms/udev/devel
In directory cvs.devel.redhat.com:/tmp/cvs-serv29354

Modified Files:
pam_console.dev udev.rules udev.spec 
Log Message:
- added Inifiniband devices (bug #147035)
- fixed pam_console.dev (bug #153250)



Index: pam_console.dev
===
RCS file: /cvs/dist/rpms/udev/devel/pam_console.dev,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- pam_console.dev 13 Dec 2004 13:00:54 -  1.9
+++ pam_console.dev 21 Apr 2005 13:11:33 -  1.10
@@ -29,7 +29,7 @@
fi
 
debug_mesg () {
-   test -z "$UDEV_LOG" -o "UDEV_LOG" != "1" && return
+   test -z "$udev_log" -o "$udev_log" != "yes" && return
mesg "$@"
}
 
@@ -40,7 +40,7 @@
SYMLINKS=""
for i in $(/usr/bin/udevinfo -r -q symlink -p "$DEVPATH"); do
[ $? -gt 0 ] && break
-   SYMLINKS="$SYMLINKS ${udev_root%%/}/$i"
+   SYMLINKS="$SYMLINKS $i"
done
debug_mesg "Restoring console permissions for $DEVNAME $SYMLINKS"
/sbin/pam_console_apply "$DEVNAME" $SYMLINKS


Index: udev.rules
===
RCS file: /cvs/dist/rpms/udev/devel/udev.rules,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- udev.rules  18 Apr 2005 10:42:10 -  1.23
+++ udev.rules  21 Apr 2005 13:11:33 -  1.24
@@ -195,8 +195,11 @@
 KERNEL=="scd[0-9]*",   SYMLINK="cdrom%e"
 KERNEL=="pcd[0-9]*",   SYMLINK="cdrom%e"
 KERNEL=="fd[0-9]*",SYMLINK="floppy%e"
-KERNEL=="nst[0-9]",SYMLINK="tape%e"
-KERNEL=="nosst[0-9]*", SYMLINK="tape%e"
+KERNEL=="nst[0-9]", BUS=="scsi",   SYMLINK="tape%e"
+KERNEL=="nosst[0-9]", BUS=="scsi", SYMLINK="tape%e"
+
+KERNEL="umad*",NAME="infiniband/%k"
+KERNEL="issm*",NAME="infiniband/%k"
 
 # do not seperate the next 2 lines!!
 KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", 
PROGRAM=="/etc/udev/scripts/ide-media.sh %k", RESULT=="floppy", 
SYMLINK="floppy%e", NAME{ignore_remove, all_partitions}="%k"


Index: udev.spec
===
RCS file: /cvs/dist/rpms/udev/devel/udev.spec,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -r1.82 -r1.83
--- udev.spec   18 Apr 2005 10:42:19 -  1.82
+++ udev.spec   21 Apr 2005 13:11:33 -  1.83
@@ -7,7 +7,7 @@
 Summary: A userspace implementation of devfs
 Name: udev
 Version: 057
-Release: 1
+Release: 2
 License: GPL
 Group: System Environment/Base
 %if !%{with_persistent}
@@ -287,6 +287,10 @@
 %endif
 
 %changelog
+* Thu Apr 21 2005 Harald Hoyer <[EMAIL PROTECTED]> - 057-2
+- added Inifiniband devices (bug #147035)
+- fixed pam_console.dev (bug #153250)
+
 * Mon Apr 18 2005 Harald Hoyer <[EMAIL PROTECTED]> - 057-1
 - version 057
 

--
fedora-cvs-commits mailing list
[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/fedora-cvs-commits
--- End Message ---


signature.asc
Description: This is a digitally signed message part
___
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] $B!y(B10000$B1_J,L5NA!y(B

2005-04-21 Thread info 
$B"#"#"#!V(B1$B1_!WJ,L5NA%]%$%s%HB#Dh%-%c%s%Z!<%se$2$^$9!*(B

$B"!(B1$B1_L5NA%]%$%s%H$H?7$7$$=P2q$$(BGET$B!*"*"*"*(B 
http://awg.webchu.com/?springg

$B!zL5NA$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72<$5$$$M"v(B
$B!z;HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_!VM-NA!W$X$*?J$_2<$5$$!#(B

$B%a!<%k$Nl9g$O2<5-(BURL$B$KJV?.2<$5$$(B
[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