[openib-general] ofa_1_2_kernel 20070208-0200 daily build status
This email was generated automatically, please do not reply Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod --with-addr_trans-mod --with-cxgb3-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.12 Passed on powerpc with linux-2.6.19 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.17 Passed on powerpc with linux-2.6.17 Passed on x86_64 with linux-2.6.18 Passed on powerpc with linux-2.6.18 Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.13 Passed on x86_64 with linux-2.6.12 Passed on ppc64 with linux-2.6.19 Passed on ia64 with linux-2.6.19 Passed on powerpc with linux-2.6.16 Passed on powerpc with linux-2.6.13 Passed on powerpc with linux-2.6.12 Passed on ppc64 with linux-2.6.16 Passed on ppc64 with linux-2.6.12 Passed on powerpc with linux-2.6.15 Passed on ppc64 with linux-2.6.17 Passed on ppc64 with linux-2.6.14 Passed on ia64 with linux-2.6.13 Passed on ppc64 with linux-2.6.18 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.15 Passed on ppc64 with linux-2.6.13 Passed on ia64 with linux-2.6.18 Passed on powerpc with linux-2.6.14 Passed on ia64 with linux-2.6.17 Passed on ppc64 with linux-2.6.15 Passed on ia64 with linux-2.6.16 Failed: Build failed on ia64 with linux-2.6.16.21-0.8-default Log: /home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.c:380: error: implicit declaration of function âregister_netevent_notifierâ /home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.c: In function âaddr_cleanupâ: /home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.c:386: error: implicit declaration of function âunregister_netevent_notifierâ make[4]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_2_kernel-20070208-0200_linux-2.6.16.21-0.8-default_ia64_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/ia64/linux-2.6.16.21-0.8-default' make: *** [kernel] Error 2 -- ___ 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] bug in netpipe
Hi I've been running netpipe over Infiniband's SDP and uncovered a race when using the -r option. The problem is when both sides close their sockets, the listening socket is closed last, which allows a faster client to try to connect to it before it closes. When this happens, next time the client tries to use the socket it gets a connection reset error. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] OpenSM/osm_ucast_lash.c: In osm_get_lash_sl, fix SL when CA ports on same switch
OpenSM/osm_ucast_lash.c: In osm_get_lash_sl, fix SL when CA ports on same switch
This change resolves an issue with strange SL assignment when
two HCAs communicate with other and are on the same switch.
Since LASH is switch to switch routing, the get_lash_sl
function was casting (the value assigned to the
variable NONE) to be a uint8_t when asked for an SL assignment
in this case. This change resolves this issue.
Signed-off-by: Thomas Sødring [EMAIL PROTECTED]
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
diff --git a/osm/opensm/osm_ucast_lash.c b/osm/opensm/osm_ucast_lash.c
index 5dfe068..e5f751c 100644
--- a/osm/opensm/osm_ucast_lash.c
+++ b/osm/opensm/osm_ucast_lash.c
@@ -1468,6 +1468,7 @@ uint8_t osm_get_lash_sl(osm_opensm_t *p_
osm_port_t *p_src_port, osm_port_t *p_dst_port)
{
unsigned dst_id;
+ unsigned src_id;
osm_switch_t *p_sw;
if (p_osm-routing_engine.ucast_build_fwd_tables != lash_process)
@@ -1482,6 +1483,10 @@ uint8_t osm_get_lash_sl(osm_opensm_t *p_
if (!p_sw || !p_sw-priv)
return OSM_DEFAULT_SL;
+ src_id = get_lash_id(p_sw);
+ if (src_id == dst_id)
+ return OSM_DEFAULT_SL;
+
return (uint8_t)((switch_t *)p_sw-priv)-routing_table[dst_id].lane;
}
___
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] please pull for 2.6.21: fix + add IB multicast support
Or Gerlitz wrote: Sean Hefty wrote: Sean Hefty (3): rdma_cm: Increment port number after close to avoid re-use. ib_sa: track multicast join/leave requests rdma_cm: add multicast communication support Assuming that you haven't look at this yet, I updated the ib_sa patch above to shorten the workqueue name, plus added a fourth patch to shorten the workqueue names for ib_addr and rdma_cm. E.g. ib_mcast_wq became ib_mcast. Roland, We are working (developing and testing) with a userspace rdma cm based multicast app over this code during the last two months and are very satisfied with it. The testing included IPoIB, the user space app and multicast interoperability between them. Roland, Can you comment on the status of this merge request? thanks, 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] Open MPI rpmbuild fails in OFED-1.2
Quoting Jeff Squyres [EMAIL PROTECTED]: Subject: Re: Open MPI rpmbuild fails in OFED-1.2 On Feb 7, 2007, at 2:49 PM, Michael S. Tsirkin wrote: My $0.02: This is another in a growing list of issues reflecting the whole build everything in DESTDIR is a problematic approach. I don't know much about RPM, and I am not exactly sure why are our source RPMs so complicated. It's a combination of two things: 1) similar to what you said below, we have lots of software packages that are all dependent upon each other -- this leads to a conglomeration of rpath's and shared library dependencies that are incorrect 2) we're trying to *use* the software when it is installed in the DESTDIR -- this means that you have to put special-case in the software so that they look for support files in both the DESTDIR *and* the final installation directory How do you mean, use? Hmm. I guess my question is - this works fine when I run OFED's configure script, why is SRPM so much more difficult? -- 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] more comments on cxgb3
On Thu, 2007-02-08 at 08:40 +0200, Michael S. Tsirkin wrote:
OK, so I looked at cxgb3 some more.
Thanks!
To summarise my previous comments, I think the cxio hal layer needs to go to
make the code readable - if I understand correctly it is there for historical
reasons only.
I can do this but its low on the list of todos.
I started looking at userspace/kernel interaction, and then
went over to other code under cxgb3 (but not core/).
- Consider a user that does e.g. create QP, but never calls mmap.
Is there some code that will clean out the unclamed mmap object?
I couldn't find it, and iwch_dealloc_ucontext does not seem to
do anything with it.
This is a bug. I've got a fix for it too.
- Passing physical address to userspace and back looks suspicios.
Especially this:
uresp.physaddr = virt_to_phys(chp-cq.queue);
Could you elaborate on the design here? What are these phy addresses
and how come userspace needs to know the phy address?
You are not doing DMA by this address, by any chance?
No, Its not used for DMA by the HW. The physaddr is passed up to the
user, and the user then mmaps() using that as the offset.
I took this code from the ipath driver. It has been pointed out to me
that this is broken for 32b userspace on a 64 kernel because mmap2()
cannot pass down 64 bits. So I need to rework this code.
- It seems that by passing in huge resource sizes, userspace will be able to
drink up unlimited amounts of kernel memory.
mthca handles this by using the mlock rlimit, should something be done here
as well?
Hmm. That's a good point. I'll put this on the todo as well. So mthca
adds to process's rlimit value as things are allocated out of kernel
memory (or maybe even anything that gets pinned)?
A couple of comments on PDBG macro.
- I'd like to suggest following the practice of prefixing macro names with
module name
(same goes for functions like get_mhp really) - unless they are local to
file.
- You are using __FUNCTION__ a lot - it might be to just to kill it,
messages are unique so you'll be able to locate the msg source anyway,
save some kernel text and logs will be shorter. In any case I think
__func__ is the recommended gcc way to get the name currently.
- comment near pr_debug definition in include/linux/kernel.h says:
/* If you are writing a driver, please use dev_dbg instead */
so it might be a good idea for PDBG to follow this rule.
- log messages do not look very informative to me.
I also think they are a bit too many of them currently.
For example, I do not think it is a good idea to print
the kernel pointers out.
For example, in code like the following:
mhp = get_mhp(rhp, (sg_list[i].lkey) 8);
if (!mhp) {
PDBG(%s %d\n, __FUNCTION__, __LINE__);
return -EIO;
}
might be better to say
MR key XXX does not exist. Exiting..
-EIO also looks like a strange error code to return here, does it not?
Maybe something like EINVAL would be more appropriate?
I'll take a todo to clean up the debug stuff.
- I wonder about the names like get_mhp - what does mhp mean?
static inline struct iwch_mr *get_mhp(struct iwch_dev *rhp, u32 mmid)
{
return idr_find(rhp-mmidr, mmid);
}
Memory Handle Pointer.
Looks like it looks up an mr. Is that right? Maybe the name shouldbe changed
to convey this meaning.
- In the following code, what does missing pdid check mean?
/*
* TBD: this is going to be moved to firmware. Missing pdid/qpid check for
now.
*/
This sounds interesting.
Does this mean the code does not validate the PD currently?
I need firmware support for this. It will be done asap and I can remove
this code entirely.
I have the same question for:
/* TBD: check perms */
in iwch_bind_mw.
BTW, does TBD stand for To Be Done here?
Yes.
Do you mean TODO really?
- iwch_sgl2pbl_map is used in several places, and seems a bit too big to be
inline
Well, it's time to go do my day job now :)
Hope this helps,
Thanks again Michael!
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
Re: [openib-general] [PATCH] IB/ipoib get net_device from ipoib_neigh instead of linux neighbour
Michael S. Tsirkin wrote: Quoting Moni Shoua [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/ipoib get net_device from ipoib_neigh instead of linux neighbour Another concern: assume that one device goes away (e.g. hotplug). It seems that neighbours whose dev field point to another device, will not be destroyed. Correct? I agree. Therefore in your design, it seems that to_ipoib_neigh()-dev will get us a pointer to device that has been removed already. I agree that this is a problem. I think we can solve this if we track all ipoib neighbours, like we do for old kernels, and then flush ipoib neighbours on any hotplug event. Roland, does this sound too awful? It think it would be best to prevent an IPoIB device from disappearing or from ib_ipoib from being unloaded as long as IPoIB device is a slave. Unfortunately, I don't see how this can be done just by fixing something in bonding or IPoIB. So hotplug is blocked potentially forever? This does not sound good. OK, so I'm dropping this thought. However, any slave knows he has a master (dev-master). What do you think about a solution where IPoIB first tries to clean up the neighbours that belong to it's master before deleting the IPoIB device? How? Let me know what do you think about that. I hope this makes sense. in IPoIB, before calling unregister_netdev do for each kernel neighbour n if n-dev == ib_dev-master delete n Michael, as I see it we have to deal with 2 cases. 1. IPoIB device is deleted (unregister_netdev) - IPoIB netdev in not in the kernel's address space. we have to make sure that no one holds a pointer to it after it is deleted. 2 ib_ipoib module is unloaded (modprobe -r) - the ipoib_neigh_destructor is not in the kernel's address space. we have to make sure no one calls to it after the module is unloaded. I think that if nothing prevents the execution of the code above it serves both cases. Do you see any problem with that? Do I have to maintain my own list of neighbours or use the kernel's arp table for that? I am trying to study the neighbour cleanup function and do something like that but I would be happy to learn from others as well. Furthermore, bond_setup_by_slave is called only for non Ethernet devices (we consider to change the logic to called only for IPoIB devices just for safety). Why is this necessary, BTW? If we don't do that, we get a memory leak because the neigh destructor will never be called for non IPoIB devices although they carry ipoib_neigh with them. How can this happen? If it does, I think we are back to where we started: to_ipoib_neigh is broken for non-IPoIB device. I thought you said only devices of the same type can be paired? The scenario is: 1. kernel allocates a neighbour structure for bond0, puts it on a skb and passed it to bond xmit function. 2. bond0 passes the skb to ipoib 3. ipoib allocates ipoib_neigh and hangs it on linux neighbour. 4. a while after that, the kernel wants to destroy the neighbour (cleanup) but doesn't call ipoib_neigh_destructor because it the neigh setup registered the destructor for ibX device. ___ 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] sharing qp between user and kernel
[EMAIL PROTECTED] wrote on Wed, 07 Feb 2007 15:50 -0800: Pete Before I dig into this anymore, do you expect this to work? Pete Are there fundamental problems with QP sharing between user Pete and kernel? It would sure be nice not to have to stick the Pete connection management aspects into the kernel. No, I wouldn't expect this to work. At first glance at least, yes, there are fundamental problems. Sharing a QP between user and kernelspace, where userspace is doing full kernel bypass (as eg mthca does -- there are NO system calls when doing post work request, poll CQ and request CQ notification operations), seems like a huge problem. I don't see any way that the kernel can keep a consistent view of the QP state unless userspace has to call into the kernel for every operation, which would kill performance. My hope was not to allow full QP sharing between user and kernel, but just a limited interface to send this kernel data now. It requires that the kernel register some physical memory, and submit the work requests. Perhaps the kernel can invoke the equivalent of the userspace post function instead of trying to use the kernel API for sending. Thanks to all for the comments. We'll keep working with non-bypass devices to see if the approach offers any advantages first. -- Pete ___ 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: fix up issues from code review
The following lightly tested patch addresses Roland's comments on IPoIB CM.
Applies on top of PATCHv6:
- Randomise RQ PSN
- Fix for modular IPv6
- MTU endian-ness fix for ICMPs
- Cosmetics
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Roland, do you want me to report the full fixed-up patch instead?
Pls let me know when IPoIB CM is in for-2.6.21,
I'll switch to that for my testing.
diff --git a/drivers/infiniband/ulp/ipoib/Kconfig
b/drivers/infiniband/ulp/ipoib/Kconfig
index 0ffca11..af78ccc 100644
--- a/drivers/infiniband/ulp/ipoib/Kconfig
+++ b/drivers/infiniband/ulp/ipoib/Kconfig
@@ -1,6 +1,6 @@
config INFINIBAND_IPOIB
tristate IP-over-InfiniBand
- depends on INFINIBAND NETDEVICES INET
+ depends on INFINIBAND NETDEVICES INET (IPV6 || IPV6=n)
---help---
Support for the IP-over-InfiniBand protocol (IPoIB). This
transports IP packets over InfiniBand so you can use your IB
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 8082d50..eb885ee 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -127,7 +127,6 @@ struct ipoib_tx_buf {
u64 mapping;
};
-#ifdef CONFIG_INFINIBAND_IPOIB_CM
struct ib_cm_id;
struct ipoib_cm_data {
@@ -181,7 +180,6 @@ struct ipoib_cm_dev_priv {
struct ib_recv_wr rx_wr;
};
-#endif
/*
* Device private locking: tx_lock protects members used in TX fast
* path (and we use LLTX so upper layers don't do extra locking).
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index e7e7cc0..8ee6f06 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -37,7 +37,7 @@
#include net/dst.h
#include net/icmp.h
-#ifdef CONFIG_IPV6
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
#include linux/icmpv6.h
#endif
@@ -170,7 +170,8 @@ static struct ib_qp *ipoib_cm_create_rx_qp(struct
net_device *dev,
}
static int ipoib_cm_modify_rx_qp(struct net_device *dev,
- struct ib_cm_id *cm_id, struct ib_qp *qp)
+ struct ib_cm_id *cm_id, struct ib_qp *qp,
+ unsigned psn)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ib_qp_attr qp_attr;
@@ -193,7 +194,7 @@ static int ipoib_cm_modify_rx_qp(struct net_device *dev,
ipoib_warn(priv, failed to init QP attr for RTR: %d\n, ret);
return ret;
}
- qp_attr.rq_psn = 0 /* FIXME */;
+ qp_attr.rq_psn = psn;
ret = ib_modify_qp(qp, qp_attr, qp_attr_mask);
if (ret) {
ipoib_warn(priv, failed to modify QP to RTR: %d\n, ret);
@@ -203,7 +204,8 @@ static int ipoib_cm_modify_rx_qp(struct net_device *dev,
}
static int ipoib_cm_send_rep(struct net_device *dev, struct ib_cm_id *cm_id,
-struct ib_qp *qp, struct ib_cm_req_event_param
*req)
+struct ib_qp *qp, struct ib_cm_req_event_param
*req,
+unsigned psn)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_cm_data data = {};
@@ -219,7 +221,7 @@ static int ipoib_cm_send_rep(struct net_device *dev, struct
ib_cm_id *cm_id,
rep.target_ack_delay = 20; /* FIXME */
rep.srq = 1;
rep.qp_num = qp-qp_num;
- rep.starting_psn = 0 /* FIXME */;
+ rep.starting_psn = psn;
return ib_send_cm_rep(cm_id, rep);
}
@@ -229,6 +231,7 @@ static int ipoib_cm_req_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *even
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_cm_rx *p;
unsigned long flags;
+ unsigned psn;
int ret;
ipoib_dbg(priv, REQ arrived\n);
@@ -243,11 +246,12 @@ static int ipoib_cm_req_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *even
goto err_qp;
}
- ret = ipoib_cm_modify_rx_qp(dev, cm_id, p-qp);
+ psn = random32() 0xff;
+ ret = ipoib_cm_modify_rx_qp(dev, cm_id, p-qp, psn);
if (ret)
goto err_modify;
- ret = ipoib_cm_send_rep(dev, cm_id, p-qp, event-param.req_rcvd);
+ ret = ipoib_cm_send_rep(dev, cm_id, p-qp, event-param.req_rcvd, psn);
if (ret) {
ipoib_warn(priv, failed to send REP: %d\n, ret);
goto err_rep;
@@ -742,7 +746,7 @@ static int ipoib_cm_send_req(struct net_device *dev,
req.retry_count = 0; /* RFC draft warns against retries */
req.rnr_retry_count = 0; /* RFC draft warns against retries */
req.max_cm_retries= 15;
- req.srq = 15;
+ req.srq = 1;
return ib_send_cm_req(id, req);
}
@@ -1041,7 +1045,7 @@ static void ipoib_cm_skb_reap(struct work_struct *work)
Re: [openib-general] sharing qp between user and kernel
On Thu, 2007-02-08 at 10:24 -0500, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Wed, 07 Feb 2007 15:50 -0800: Pete Before I dig into this anymore, do you expect this to work? Pete Are there fundamental problems with QP sharing between user Pete and kernel? It would sure be nice not to have to stick the Pete connection management aspects into the kernel. No, I wouldn't expect this to work. At first glance at least, yes, there are fundamental problems. Sharing a QP between user and kernelspace, where userspace is doing full kernel bypass (as eg mthca does -- there are NO system calls when doing post work request, poll CQ and request CQ notification operations), seems like a huge problem. I don't see any way that the kernel can keep a consistent view of the QP state unless userspace has to call into the kernel for every operation, which would kill performance. My hope was not to allow full QP sharing between user and kernel, but just a limited interface to send this kernel data now. It requires that the kernel register some physical memory, and submit the work requests. Perhaps the kernel can invoke the equivalent of the userspace post function instead of trying to use the kernel API for sending. You could map the kernel data into the user process and then have the user process post the WR. But the user process would have to have that memory registered as part of a MR to post it. It could be done though. So basically instead of sharing QP, give your kernel module access memory from a registered MR. The kernel module can produce the data in that memory then tell the user process to post the WR... 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
Re: [openib-general] more comments on cxgb3
- It seems that by passing in huge resource sizes, userspace will be able to
drink up unlimited amounts of kernel memory.
mthca handles this by using the mlock rlimit, should something be done
here
as well?
Hmm. That's a good point. I'll put this on the todo as well. So mthca
adds to process's rlimit value as things are allocated out of kernel
memory (or maybe even anything that gets pinned)?
Yes. The code is actually in uverbs core, mthca uses that.
- I wonder about the names like get_mhp - what does mhp mean?
static inline struct iwch_mr *get_mhp(struct iwch_dev *rhp, u32 mmid)
{
return idr_find(rhp-mmidr, mmid);
}
Memory Handle Pointer.
hmm, what's a Handle? Maybe a better name can be found.
--
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] dapl broken for iWARP
That is correct. I am working with Krishna on it. Expect patches soon. By the way the problem is not DAPL specific and so is a proposed solution. There are 3 aspects of the solution. One is APIs. We suggest that we do not augment these. That is a connection requestor sets its QP RDMA ORD and IRD. When connection is established user can check the QP RDMA ORD and IRD to see what he has now to use over the connection. We may consider to extend QP attributes to support transport specific parameters passing in the future. For example, iWARP MPA CRC request. Second is the semantic that CM provides. The proposal is to match IBCM semantic. That is CM guarantee that local IRD is = remote ORD. This guarantees that incoming RDMA Read requests will not overwhelm the QP RDMA Read capabilities. Again there is not changes to IBCM only to IWCM. Notice that as part of this IWCM will pass down to driver and extract from driver needed info. The final part is iWARP CM extension to exchange RDMA ORD, IRD. This is similar to IBTA Annex for IP Addressing. The harder part that this will eventually require IETF MPA spec extension, and the fact that MPA protocol is implemented in RNIC HW by many vendors, and hence can not be done by IWCM itself. Thanks, 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: Steve Wise [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 6:12 PM To: Arlin Davis Cc: openib-general Subject: Re: [openib-general] dapl broken for iWARP On Wed, 2007-02-07 at 15:05 -0800, Arlin Davis wrote: Steve Wise wrote: On Wed, 2007-02-07 at 14:02 -0600, Steve Wise wrote: Arlin, The OFED dapl code is assuming the responder_resources and initiator_depth passed up on a connection request event are from the remote peer. This doesn't happen for iWARP. In the current iWARP specifications, its up to the application to exchange this information somehow. So these are defaulting to 0 on the server side of any dapl connection over iWARP. This is a fairly recent change, I think. We need to come up with some way to deal with this for OFED 1.2 IMO. Yes, this was changed recently to sync up with the rdma_cm changes that exposed the values. The IWCM could set these to the device max values for instance. That would work fine as long as you know the remote settings will be equal or better. The provider just sets the min of local device max values and the remote values provided with the request. I know Krishna Kumar is working on a solution for exchanging this info in private data so the IWCM can do the right thing. Stay tuned for a patch series to review for this. But this functionality is definitely post OFED-1.2. So for the OFED-1.2, I will set these to the device max in the IWCM. Assuming the other side is OFED 1.2 DAPL, then it will work fine. 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 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] more comments on cxgb3
- Consider a user that does e.g. create QP, but never calls mmap.
Is there some code that will clean out the unclamed mmap object?
I couldn't find it, and iwch_dealloc_ucontext does not seem to
do anything with it.
BTW: Here is my fix for this.
-
Clean up pending mmaps on ucontext deallocation.
From: Steve Wise [EMAIL PROTECTED]
Free all pending mmap structs when the ucontext is deallocated.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.c |1 +
drivers/infiniband/hw/cxgb3/iwch_provider.h | 15 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index db2b0a8..98568ee 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -99,6 +99,7 @@ static int iwch_dealloc_ucontext(struct
struct iwch_dev *rhp = to_iwch_dev(context-device);
struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
PDBG(%s context %p\n, __FUNCTION__, context);
+ free_mmaps(ucontext);
cxio_release_ucontext(rhp-rdev, ucontext-uctx);
kfree(ucontext);
return 0;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.h
b/drivers/infiniband/hw/cxgb3/iwch_provider.h
index 1ede8a7..c8c07ee 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.h
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.h
@@ -199,6 +199,21 @@ struct iwch_mm_entry {
unsigned len;
};
+static inline void free_mmaps(struct iwch_ucontext *ucontext)
+{
+ struct list_head *pos, *nxt;
+ struct iwch_mm_entry *mm;
+
+ spin_lock(ucontext-mmap_lock);
+ list_for_each_safe(pos, nxt, ucontext-mmaps) {
+ mm = list_entry(pos, struct iwch_mm_entry, entry);
+ list_del(mm-entry);
+ kfree(mm);
+ }
+ spin_unlock(ucontext-mmap_lock);
+ return;
+}
+
static inline struct iwch_mm_entry *remove_mmap(struct iwch_ucontext *ucontext,
u64 addr, unsigned len)
{
___
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: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
The windows open IB has decided on using a BSD only license. The common implementation of pthreads as far as I know is LGPL, which means that it can not be used in open IB. The only two ways that I see around this are 1) Change the license of open IB windows which might be a complicated thing. 2) Find an implementation of pthreads that is BSD. Thanks Tzachi -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:46 PM To: Tzachi Dar; Yossi Leybovich Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote: Tzachi, Yossi, please join the thread. What do you think about distributing a copy of the pthread DLL with opensm? Any news here? Thanks. Sasha -- Yevgeny. Original Message Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] Date: Fri, 19 Jan 2007 00:20:32 +0200 From: Sasha Khapyorsky [EMAIL PROTECTED] To: Michael S. Tsirkin [EMAIL PROTECTED] CC: Yevgeny Kliteynik [EMAIL PROTECTED], OPENIB openib-general@openib.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote: Quoting Sasha Khapyorsky [EMAIL PROTECTED]: Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote: 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. So this seems to be good option for OpenSM on Windows. Right? No idea. Distributing a copy of the pthread DLL with opensm does not look like a problem. But is it worth it? Sure, it makes windows porting much more transparent and let us to use standard *nix stuff w/out #ifndef WIN32. Other (generic) benefit is that posix is more standard and powerful than wrappers like complib. 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] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
On Thu, Feb 08, 2007 at 10:23:11AM -0800, Sean Hefty wrote: The active side clearly cannot learn what the SLID of the passive side's router should be. We don't want to have the routers snoop and alter CM GMPs. The passive side cannot use information from the LRH to get the router LID since the LRH may not be reversible. The only option seems to be to have the passive side do a path record query on a SGID in the CM REQ... This is a spec problem unfortunately. Yes and I would expect that this would be changed. Looking at the problem more, I think that the issue extends to the remote port LID as well. My expectation with a local path record query is that the SLID is the local port, and the DLID is the local router. This should be sufficient for one-way UD traffic, but for connected traffic we still need to discover the remote router and remote port LIDs. Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a huge PITA.. [IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID should not be validated against the QP context since it makes it extra hard for multipath routing and QoS to work...] Here is one thought on how to do this: To meet this rule each side of the CM must take the SLID from the incoming LRH as the DLID for the connection. This SLID will be one of the SLIDs for the local router. The other side doesn't need to know what it is. The passive side will get the router SLID from the REQ and the active side gets it from the ACK. The passive side is easy, it just path record queries the DGID and requests the DLID == the incoming LRH.SLID. The nasty problem is with the active side - CMA will select a router lid it uses as the DLID and the router may select a different LID for it to use as the SLID when it processes the ACK. By C9-54 they have to be the same : So the active side might have to do another path record query to move its DLID and SL to match the routers choosen SLID. Double suck :P Overarching all of this is some mechanism where the SM and all the routers collaborate to keep the router SLID the same for the duration of every RC flow. (One simple way would be to have the SM encode the SLID it wants to router to pick in the Flow Label or TClass..) Suck. Another idea would be to encode the local router SLID in the flow label and have the CM exchange and use asymetric flow labels.. That would move control over SL selection into the endpoints and remove the possible 2nd pathrecord query from the active side - but I haven't looked if CM can exchange flow labels in the ACK.. I think that we need a way for the local node to query the remote SA to obtain this information. Or we need a new path record for routable paths that includes this information. Being able to query doesn't really help matters since you still can't tell the router what SLID to use.. The main idea is that the router lid is only useful to the endpoint on the same subnet so there is no reason to make the non-local side fetch it. Jason ___ 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: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
On 20:31 Thu 08 Feb , Tzachi Dar wrote:
The windows open IB has decided on using a BSD only license.
The common implementation of pthreads as far as I know is LGPL, which
means that it can not be used in open IB.
Why not? AFAIK it works perfectly (see (5,6 and Preamble)):
http://www.gnu.org/copyleft/lesser.html
And of course there are tons of examples when BSD software links against
LGPLed glibc.
The only two ways that I see around this are 1) Change the license of
open IB windows which might be a complicated thing. 2) Find an
implementation of pthreads that is BSD.
BTW, just wondering... What is relation between windows open IB and OFA
(and OFA's dual-license rule)?
Sasha
Thanks
Tzachi
-Original Message-
From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 7:46 PM
To: Tzachi Dar; Yossi Leybovich
Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock
Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2]
opensm: sigusr1: syslog() fixes]]
On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote:
Tzachi, Yossi, please join the thread.
What do you think about distributing a copy of the pthread DLL with
opensm?
Any news here? Thanks.
Sasha
-- Yevgeny.
Original Message
Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1:
syslog() fixes]
Date: Fri, 19 Jan 2007 00:20:32 +0200
From: Sasha Khapyorsky [EMAIL PROTECTED]
To: Michael S. Tsirkin [EMAIL PROTECTED]
CC: Yevgeny Kliteynik [EMAIL PROTECTED],
OPENIB openib-general@openib.org
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote:
Quoting Sasha Khapyorsky [EMAIL PROTECTED]:
Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1:
syslog() fixes]
On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote:
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.
So this seems to be good option for OpenSM on Windows. Right?
No idea. Distributing a copy of the pthread DLL with
opensm does not
look like a problem. But is it worth it?
Sure, it makes windows porting much more transparent and
let us to use
standard *nix stuff w/out #ifndef WIN32. Other (generic) benefit is
that posix is more standard and powerful than wrappers like complib.
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] more comments on cxgb3
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index db2b0a8..98568ee 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -99,6 +99,7 @@ static int iwch_dealloc_ucontext(struct
struct iwch_dev *rhp = to_iwch_dev(context-device);
struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
PDBG(%s context %p\n, __FUNCTION__, context);
+free_mmaps(ucontext);
cxio_release_ucontext(rhp-rdev, ucontext-uctx);
kfree(ucontext);
return 0;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.h
b/drivers/infiniband/hw/cxgb3/iwch_provider.h
index 1ede8a7..c8c07ee 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.h
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.h
@@ -199,6 +199,21 @@ struct iwch_mm_entry {
unsigned len;
};
+static inline void free_mmaps(struct iwch_ucontext *ucontext)
+{
+struct list_head *pos, *nxt;
+struct iwch_mm_entry *mm;
+
+spin_lock(ucontext-mmap_lock);
+list_for_each_safe(pos, nxt, ucontext-mmaps) {
+mm = list_entry(pos, struct iwch_mm_entry, entry);
+list_del(mm-entry);
+kfree(mm);
+}
+spin_unlock(ucontext-mmap_lock);
+return;
+}
Since you only have one caller, I would suggest just open-coding the
deletion at the call-site (since that function is really too big to
inline if it ever grows another caller). And I don't think you need
the locking either, since there better be no one else looking at the
context structure while you're in the process of freeing it.
Something like:
struct iwch_dev *rhp = to_iwch_dev(context-device);
struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
struct iwch_mm_entry *mm, *tmp;
PDBG(%s context %p\n, __FUNCTION__, context);
list_for_each_entry_safe(mm, tmp, ucontext-mmaps)
kfree(mm);
cxio_release_ucontext(rhp-rdev, ucontext-uctx);
kfree(ucontext);
return 0;
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a huge PITA.. [IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID should not be validated against the QP context since it makes it extra hard for multipath routing and QoS to work...] Yes - this gets messy. Here is one thought on how to do this: To meet this rule each side of the CM must take the SLID from the incoming LRH as the DLID for the connection. This SLID will be one of the SLIDs for the local router. The other side doesn't need to know what it is. The passive side will get the router SLID from the REQ and the active side gets it from the ACK. The passive side is easy, it just path record queries the DGID and requests the DLID == the incoming LRH.SLID. This requires that the passive side be able to issue path record queries, but I think that it could work for static routes. A point was made to me that the remote side could be a TCA without query capabilities. There's still the issue of what value is carried in the remote port LID in the CM REQ (12.7.21), and I haven't even gotten to APM yet... The nasty problem is with the active side - CMA will select a router lid it uses as the DLID and the router may select a different LID for it to use as the SLID when it processes the ACK. By C9-54 they have to be the same : So the active side might have to do another path record query to move its DLID and SL to match the routers choosen SLID. Double suck :P As long as the SA and local routers are in sync, we may be okay here without a second path record query. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH ofed-1.2] libehca: fix build error with disable-libcheck option
This patch fix libehca build errors if disable-libcheck option is choosen. Applied ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH 2/5] No need to disable interrupts for mmap locking.
From: Steve Wise [EMAIL PROTECTED]
Lock mmap_lock is never taken from non-process context, so just use
bare spin_lock()/spin_unlock().
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.h
b/drivers/infiniband/hw/cxgb3/iwch_provider.h
index a8cfeaf..1ede8a7 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.h
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.h
@@ -205,29 +205,29 @@ static inline struct iwch_mm_entry *remo
struct list_head *pos, *nxt;
struct iwch_mm_entry *mm;
- spin_lock_irq(ucontext-mmap_lock);
+ spin_lock(ucontext-mmap_lock);
list_for_each_safe(pos, nxt, ucontext-mmaps) {
mm = list_entry(pos, struct iwch_mm_entry, entry);
if (mm-addr == addr mm-len == len) {
list_del_init(mm-entry);
- spin_unlock_irq(ucontext-mmap_lock);
+ spin_unlock(ucontext-mmap_lock);
PDBG(%s addr 0x%llx len %d\n, __FUNCTION__, mm-addr,
mm-len);
return mm;
}
}
- spin_unlock_irq(ucontext-mmap_lock);
+ spin_unlock(ucontext-mmap_lock);
return NULL;
}
static inline void insert_mmap(struct iwch_ucontext *ucontext,
struct iwch_mm_entry *mm)
{
- spin_lock_irq(ucontext-mmap_lock);
+ spin_lock(ucontext-mmap_lock);
PDBG(%s addr 0x%llx len %d\n, __FUNCTION__, mm-addr, mm-len);
list_add_tail(mm-entry, ucontext-mmaps);
- spin_unlock_irq(ucontext-mmap_lock);
+ spin_unlock(ucontext-mmap_lock);
}
enum iwch_qp_attr_mask {
___
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/5] iw_cxgb3 - misc cleanup and fixes
Here are some fixes to address various comments from Michael and Roland. This is _not_ for ofed_1_2, but rather for merging into 2.6.21. 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 3/5] Clean up pending mmaps on ucontext deallocation.
From: Steve Wise [EMAIL PROTECTED]
Free all pending mmap structs when the ucontext is deallocated.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index db2b0a8..85484ac 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -98,7 +98,11 @@ static int iwch_dealloc_ucontext(struct
{
struct iwch_dev *rhp = to_iwch_dev(context-device);
struct iwch_ucontext *ucontext = to_iwch_ucontext(context);
+ struct iwch_mm_entry *mm, *tmp;
+
PDBG(%s context %p\n, __FUNCTION__, context);
+ list_for_each_entry_safe(mm, tmp, ucontext-mmaps, entry)
+ kfree(mm);
cxio_release_ucontext(rhp-rdev, ucontext-uctx);
kfree(ucontext);
return 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] [PATCH 4/5] Get rid of static rdev table.
From: Steve Wise [EMAIL PROTECTED]
Use a liked list.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 57 +--
drivers/infiniband/hw/cxgb3/core/cxio_hal.h |2 -
2 files changed, 19 insertions(+), 40 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
index 2c4e351..acffe16 100644
--- a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c
@@ -43,49 +43,28 @@ #include cxio_hal.h
#include cxgb3_offload.h
#include sge_defs.h
-static struct cxio_rdev *rdev_tbl[T3_MAX_NUM_RNIC];
+static LIST_HEAD(rdev_list);
static cxio_hal_ev_callback_func_t cxio_ev_cb = NULL;
static inline struct cxio_rdev *cxio_hal_find_rdev_by_name(char *dev_name)
{
- int i;
- for (i = 0; i T3_MAX_NUM_RNIC; i++)
- if (rdev_tbl[i])
- if (!strcmp(rdev_tbl[i]-dev_name, dev_name))
- return rdev_tbl[i];
+ struct cxio_rdev *rdev;
+
+ list_for_each_entry(rdev, rdev_list, entry)
+ if (!strcmp(rdev-dev_name, dev_name))
+ return rdev;
return NULL;
}
static inline struct cxio_rdev *cxio_hal_find_rdev_by_t3cdev(struct t3cdev
*tdev)
{
- int i;
- for (i = 0; i T3_MAX_NUM_RNIC; i++)
- if (rdev_tbl[i])
- if (rdev_tbl[i]-t3cdev_p == tdev)
- return rdev_tbl[i];
- return NULL;
-}
-
-static inline int cxio_hal_add_rdev(struct cxio_rdev *rdev_p)
-{
- int i;
- for (i = 0; i T3_MAX_NUM_RNIC; i++)
- if (!rdev_tbl[i]) {
- rdev_tbl[i] = rdev_p;
- break;
- }
- return (i == T3_MAX_NUM_RNIC);
-}
+ struct cxio_rdev *rdev;
-static inline void cxio_hal_delete_rdev(struct cxio_rdev *rdev_p)
-{
- int i;
- for (i = 0; i T3_MAX_NUM_RNIC; i++)
- if (rdev_tbl[i] == rdev_p) {
- rdev_tbl[i] = NULL;
- break;
- }
+ list_for_each_entry(rdev, rdev_list, entry)
+ if (rdev-t3cdev_p == tdev)
+ return rdev;
+ return NULL;
}
int cxio_hal_cq_op(struct cxio_rdev *rdev_p, struct t3_cq *cq,
@@ -937,8 +916,7 @@ int cxio_rdev_open(struct cxio_rdev *rde
return -EINVAL;
}
- if (cxio_hal_add_rdev(rdev_p))
- return -ENOMEM;
+ list_add_tail(rdev_p-entry, rdev_list);
PDBG(%s opening rnic dev %s\n, __FUNCTION__, rdev_p-dev_name);
memset(rdev_p-ctrl_qp, 0, sizeof(rdev_p-ctrl_qp));
@@ -1018,7 +996,7 @@ err3:
err2:
cxio_hal_destroy_ctrl_qp(rdev_p);
err1:
- cxio_hal_delete_rdev(rdev_p);
+ list_del(rdev_p-entry);
return err;
}
@@ -1027,7 +1005,7 @@ void cxio_rdev_close(struct cxio_rdev *r
if (rdev_p) {
cxio_hal_pblpool_destroy(rdev_p);
cxio_hal_rqtpool_destroy(rdev_p);
- cxio_hal_delete_rdev(rdev_p);
+ list_del(rdev_p-entry);
rdev_p-t3cdev_p-ulp = NULL;
cxio_hal_destroy_ctrl_qp(rdev_p);
cxio_hal_destroy_resource(rdev_p-rscp);
@@ -1038,7 +1016,6 @@ int __init cxio_hal_init(void)
{
if (cxio_hal_init_rhdl_resource(T3_MAX_NUM_RI))
return -ENOMEM;
- memset(rdev_tbl, 0, T3_MAX_NUM_RNIC * sizeof(void *));
t3_register_cpl_handler(CPL_ASYNC_NOTIF, cxio_hal_ev_handler);
return 0;
}
@@ -1046,9 +1023,11 @@ int __init cxio_hal_init(void)
void __exit cxio_hal_exit(void)
{
int i;
+ struct cxio_rdev *rdev, *tmp;
+
t3_register_cpl_handler(CPL_ASYNC_NOTIF, NULL);
- for (i = 0; i T3_MAX_NUM_RNIC; i++)
- cxio_rdev_close(rdev_tbl[i]);
+ list_for_each_entry_safe(rdev, tmp, rdev_list, entry)
+ cxio_rdev_close(rdev);
cxio_hal_destroy_rhdl_resource();
}
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.h
b/drivers/infiniband/hw/cxgb3/core/cxio_hal.h
index d5ae282..8fb2999 100644
--- a/drivers/infiniband/hw/cxgb3/core/cxio_hal.h
+++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.h
@@ -47,7 +47,6 @@ #define T3_CTRL_QP_SIZE_LOG2 8
#define T3_CTRL_CQ_ID0
/* TBD */
-#define T3_MAX_NUM_RNIC 8
#define T3_MAX_NUM_RI (115)
#define T3_MAX_NUM_QP (115)
#define T3_MAX_NUM_CQ (115)
@@ -106,6 +105,7 @@ struct cxio_rdev {
struct cxio_ucontext uctx;
struct gen_pool *pbl_pool;
struct gen_pool *rqt_pool;
+ struct list_head entry;
};
static inline int cxio_num_stags(struct cxio_rdev *rdev_p)
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
[openib-general] [PATCH 5/5] Hold the iwch device mutex around cxio_rdev_open().
From: Steve Wise [EMAIL PROTECTED]
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch.c
b/drivers/infiniband/hw/cxgb3/iwch.c
index 0c95f2c..c353a9b 100644
--- a/drivers/infiniband/hw/cxgb3/iwch.c
+++ b/drivers/infiniband/hw/cxgb3/iwch.c
@@ -119,7 +119,10 @@ static void open_rnic_dev(struct t3cdev
rnicp-rdev.ulp = rnicp;
rnicp-rdev.t3cdev_p = tdev;
+ mutex_lock(dev_mutex);
+
if (cxio_rdev_open(rnicp-rdev)) {
+ mutex_unlock(dev_mutex);
printk(KERN_ERR MOD Unable to open CXIO rdev\n);
ib_dealloc_device(rnicp-ibdev);
return;
@@ -127,7 +130,6 @@ static void open_rnic_dev(struct t3cdev
rnic_init(rnicp);
- mutex_lock(dev_mutex);
list_add_tail(rnicp-entry, dev_list);
mutex_unlock(dev_mutex);
___
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] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
On Thu, 2007-02-08 at 14:54, Sean Hefty wrote: Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a huge PITA.. [IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID should not be validated against the QP context since it makes it extra hard for multipath routing and QoS to work...] Yes - this gets messy. Here is one thought on how to do this: To meet this rule each side of the CM must take the SLID from the incoming LRH as the DLID for the connection. This SLID will be one of the SLIDs for the local router. The other side doesn't need to know what it is. The passive side will get the router SLID from the REQ and the active side gets it from the ACK. The passive side is easy, it just path record queries the DGID and requests the DLID == the incoming LRH.SLID. This requires that the passive side be able to issue path record queries, but I think that it could work for static routes. A point was made to me that the remote side could be a TCA without query capabilities. Are you referring to SA query capabilities ? Would such a device just be expected to work without change in an IB routed environment anyway ? -- Hal There's still the issue of what value is carried in the remote port LID in the CM REQ (12.7.21), and I haven't even gotten to APM yet... The nasty problem is with the active side - CMA will select a router lid it uses as the DLID and the router may select a different LID for it to use as the SLID when it processes the ACK. By C9-54 they have to be the same : So the active side might have to do another path record query to move its DLID and SL to match the routers choosen SLID. Double suck :P As long as the SA and local routers are in sync, we may be okay here without a second path record query. - 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 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] new OFED 1.2 package
New OFED package was uploaded to the OFA server: http://www.openfabrics.org/builds/ofed-1.2/OFED-1.2-20070208-1508.tgz Many of the issues reported on the previous version are resolved (bugzilla will be updated next week). Since we had lab restructuring we did only basic tests on RHEL up4 and SLES10 (x86 and x86_64) All - we are going for our weekend now. Please report all issues you encounter so we will be able to fix and do the alpha release on Monday. Thanks, Tziporet Vlad ___ 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: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
See bellow. Thanks Tzachi -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 9:47 PM To: Tzachi Dar Cc: Yossi Leybovich; Gilad Shainer; Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] On 20:31 Thu 08 Feb , Tzachi Dar wrote: The windows open IB has decided on using a BSD only license. The common implementation of pthreads as far as I know is LGPL, which means that it can not be used in open IB. Why not? AFAIK it works perfectly (see (5,6 and Preamble)): http://www.gnu.org/copyleft/lesser.html And of course there are tons of examples when BSD software links against LGPLed glibc. I can of course write you an answer that will be more than 5 pages long of why *I* don't think that Using GPL software is bad for everyone, but I guess that my opinion doesn't really meter, so I Won't do it. The page that you have referenced is of the GNU org, and even there it is hard to say that they are trying to encourage you to use the LGPL license. In any case, the main point is that When open IB windows was formed there was a general decision that it will use BSD license. If we Start having components with the LGPL this will break that decision, and therefore this requires some voting of the open IB organization. The only two ways that I see around this are 1) Change the license of open IB windows which might be a complicated thing. 2) Find an implementation of pthreads that is BSD. BTW, just wondering... What is relation between windows open IB and OFA (and OFA's dual-license rule)? Well, the way I see it one can take code from the Linux part under the BSD licance and use it in The windows part. The otherway around seems fine to me but some say that since the windows BSD liscance Reqires that some text will always remain there, the other way around is not possibale. As I'm not an Expert in that erea I don't know who is right. Sasha Thanks Tzachi -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:46 PM To: Tzachi Dar; Yossi Leybovich Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote: Tzachi, Yossi, please join the thread. What do you think about distributing a copy of the pthread DLL with opensm? Any news here? Thanks. Sasha -- Yevgeny. Original Message Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] Date: Fri, 19 Jan 2007 00:20:32 +0200 From: Sasha Khapyorsky [EMAIL PROTECTED] To: Michael S. Tsirkin [EMAIL PROTECTED] CC: Yevgeny Kliteynik [EMAIL PROTECTED], OPENIB openib-general@openib.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote: Quoting Sasha Khapyorsky [EMAIL PROTECTED]: Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote: 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. So this seems to be good option for OpenSM on Windows. Right? No idea. Distributing a copy of the pthread DLL with opensm does not look like a problem. But is it worth it? Sure, it makes windows porting much more transparent and let us to use standard *nix stuff w/out #ifndef WIN32. Other (generic) benefit is that posix is more standard and powerful than wrappers like complib. 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] [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
Windows Open IB is part of OpenFabrics. OpenFabrics includes Linux and Windows communities. The Linux code is dual license while the Windows code is BSD only. Gilad. -Original Message- From: Tzachi Dar Sent: Thursday, February 08, 2007 1:24 PM To: Sasha Khapyorsky Cc: Yossi Leybovich; Gilad Shainer; Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: RE: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] See bellow. Thanks Tzachi -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 9:47 PM To: Tzachi Dar Cc: Yossi Leybovich; Gilad Shainer; Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] On 20:31 Thu 08 Feb , Tzachi Dar wrote: The windows open IB has decided on using a BSD only license. The common implementation of pthreads as far as I know is LGPL, which means that it can not be used in open IB. Why not? AFAIK it works perfectly (see (5,6 and Preamble)): http://www.gnu.org/copyleft/lesser.html And of course there are tons of examples when BSD software links against LGPLed glibc. I can of course write you an answer that will be more than 5 pages long of why *I* don't think that Using GPL software is bad for everyone, but I guess that my opinion doesn't really meter, so I Won't do it. The page that you have referenced is of the GNU org, and even there it is hard to say that they are trying to encourage you to use the LGPL license. In any case, the main point is that When open IB windows was formed there was a general decision that it will use BSD license. If we Start having components with the LGPL this will break that decision, and therefore this requires some voting of the open IB organization. The only two ways that I see around this are 1) Change the license of open IB windows which might be a complicated thing. 2) Find an implementation of pthreads that is BSD. BTW, just wondering... What is relation between windows open IB and OFA (and OFA's dual-license rule)? Well, the way I see it one can take code from the Linux part under the BSD licance and use it in The windows part. The otherway around seems fine to me but some say that since the windows BSD liscance Reqires that some text will always remain there, the other way around is not possibale. As I'm not an Expert in that erea I don't know who is right. Sasha Thanks Tzachi -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:46 PM To: Tzachi Dar; Yossi Leybovich Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote: Tzachi, Yossi, please join the thread. What do you think about distributing a copy of the pthread DLL with opensm? Any news here? Thanks. Sasha -- Yevgeny. Original Message Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] Date: Fri, 19 Jan 2007 00:20:32 +0200 From: Sasha Khapyorsky [EMAIL PROTECTED] To: Michael S. Tsirkin [EMAIL PROTECTED] CC: Yevgeny Kliteynik [EMAIL PROTECTED], OPENIB openib-general@openib.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote: Quoting Sasha Khapyorsky [EMAIL PROTECTED]: Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes] On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote: 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. So this seems to be good option for OpenSM on Windows. Right? No idea. Distributing a copy of the pthread DLL with opensm does not look like a problem. But is it worth it? Sure, it makes windows porting much more transparent and let us to use standard *nix stuff w/out #ifndef WIN32. Other (generic) benefit is that posix is more standard and powerful than wrappers like complib. Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To
Re: [openib-general] Immediate data question
At 03:41 PM 2/7/2007, Roland Dreier wrote: Changqing What I mean is that, is there any performance penalty Changqing for receiver's overall performance if RNR happens Changqing continuously on one of the QP ? Not for the receiver, but the sender will be severely slowed down by having to wait for the RNR timeouts. RNR = Receiver Not Ready so by definition, the data flow isn't going to progress until the receiver is ready to receive data. If a receive QP enters RNR for a RC, then it is likely not progressing as desired. RNR was initially put in place to enable a receiver to create back pressure to the sender without causing a fatal error condition. It should rarely be entered and therefore should have negligible impact on overall performance however when a RNR occurs, no forward progress will occur so performance is essentially zero. Mike ___ 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] dapl broken for iWARP
At 07:43 AM 2/8/2007, Kanevsky, Arkady wrote: That is correct. I am working with Krishna on it. Expect patches soon. By the way the problem is not DAPL specific and so is a proposed solution. There are 3 aspects of the solution. One is APIs. We suggest that we do not augment these. That is a connection requestor sets its QP RDMA ORD and IRD. When connection is established user can check the QP RDMA ORD and IRD to see what he has now to use over the connection. We may consider to extend QP attributes to support transport specific parameters passing in the future. For example, iWARP MPA CRC request. Second is the semantic that CM provides. The proposal is to match IBCM semantic. That is CM guarantee that local IRD is = remote ORD. This guarantees that incoming RDMA Read requests will not overwhelm the QP RDMA Read capabilities. Again there is not changes to IBCM only to IWCM. Notice that as part of this IWCM will pass down to driver and extract from driver needed info. The final part is iWARP CM extension to exchange RDMA ORD, IRD. This is similar to IBTA Annex for IP Addressing. The harder part that this will eventually require IETF MPA spec extension, and the fact that MPA protocol is implemented in RNIC HW by many vendors, and hence can not be done by IWCM itself. We looked at this quite a bit during the creation of the specification. All of the targeted usage models exchange this information as part of their hello or login exchanges.As such, the hum was to not change MPA to communicate such information and leave it to software to exchange these values through existing mechanisms. I seriously doubt there will be much support for modifying the MPA specification at this stage since the implementations are largely complete and a modification would have to deal with the legacy interoperability issue which likely would be solved in software any way. It would be simpler to simply modify the underlying DAPL implementation to exchange the information and keep this hidden from both the application and the RNIC providers. Mike Thanks, 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: Steve Wise [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 6:12 PM To: Arlin Davis Cc: openib-general Subject: Re: [openib-general] dapl broken for iWARP On Wed, 2007-02-07 at 15:05 -0800, Arlin Davis wrote: Steve Wise wrote: On Wed, 2007-02-07 at 14:02 -0600, Steve Wise wrote: Arlin, The OFED dapl code is assuming the responder_resources and initiator_depth passed up on a connection request event are from the remote peer. This doesn't happen for iWARP. In the current iWARP specifications, its up to the application to exchange this information somehow. So these are defaulting to 0 on the server side of any dapl connection over iWARP. This is a fairly recent change, I think. We need to come up with some way to deal with this for OFED 1.2 IMO. Yes, this was changed recently to sync up with the rdma_cm changes that exposed the values. The IWCM could set these to the device max values for instance. That would work fine as long as you know the remote settings will be equal or better. The provider just sets the min of local device max values and the remote values provided with the request. I know Krishna Kumar is working on a solution for exchanging this info in private data so the IWCM can do the right thing. Stay tuned for a patch series to review for this. But this functionality is definitely post OFED-1.2. So for the OFED-1.2, I will set these to the device max in the IWCM. Assuming the other side is OFED 1.2 DAPL, then it will work fine. 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 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] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
At 12:39 PM 2/8/2007, Hal Rosenstock wrote: On Thu, 2007-02-08 at 14:54, Sean Hefty wrote: Hum, you mean to meet the LID validation rules of 9.6.1.5? That is a huge PITA.. [IMHO, 9.6.1.5 C9-54 is a mistake, if there is a GRH then the LRH.SLID should not be validated against the QP context since it makes it extra hard for multipath routing and QoS to work...] If you examine the prior diagram, the packet validation is quite precise and intent on catching any misrouted packets as early in the validation process as possible. This particular compliance statement makes it clear as to the type of connection and how to pattern match. The protocol was designed to work witin a single subnet as well as across subnets. Hence, the GRH must be validated in conjunction with the LRH and the QP context in order to insure an intermediate component did not misroute the packet.As described, a RC QP must flow through at most a single path at any given time in order to insure packet ordering is maintained (IB requires strong ordering so multi-path within a single RC is not allowed). As for QoS, one can arbitrate a packet for a RC QP relative to other flows without any additional complexity. If one wants to segregate a set of RC QP onto different paths as well as arbitration slots that is allowed and supported by the architecture even if going between the same set of ports - simply use multiple LID and SL during connection establishment. Mike Yes - this gets messy. Here is one thought on how to do this: To meet this rule each side of the CM must take the SLID from the incoming LRH as the DLID for the connection. This SLID will be one of the SLIDs for the local router. The other side doesn't need to know what it is. The passive side will get the router SLID from the REQ and the active side gets it from the ACK. The passive side is easy, it just path record queries the DGID and requests the DLID == the incoming LRH.SLID. This requires that the passive side be able to issue path record queries, but I think that it could work for static routes. A point was made to me that the remote side could be a TCA without query capabilities. Are you referring to SA query capabilities ? Would such a device just be expected to work without change in an IB routed environment anyway ? -- Hal There's still the issue of what value is carried in the remote port LID in the CM REQ (12.7.21), and I haven't even gotten to APM yet... The nasty problem is with the active side - CMA will select a router lid it uses as the DLID and the router may select a different LID for it to use as the SLID when it processes the ACK. By C9-54 they have to be the same : So the active side might have to do another path record query to move its DLID and SL to match the routers choosen SLID. Double suck :P As long as the SA and local routers are in sync, we may be okay here without a second path record query. - 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 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] [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
On 23:24 Thu 08 Feb , Tzachi Dar wrote: The windows open IB has decided on using a BSD only license. The common implementation of pthreads as far as I know is LGPL, which means that it can not be used in open IB. Why not? AFAIK it works perfectly (see (5,6 and Preamble)): http://www.gnu.org/copyleft/lesser.html And of course there are tons of examples when BSD software links against LGPLed glibc. I can of course write you an answer that will be more than 5 pages long of why *I* don't think that Using GPL software is bad for everyone, but I guess that my opinion doesn't really meter, so I Won't do it. I didn't mean to take it in this direction, sorry. I reffered original LGPL text where stated explicitly that non-(L)GPL programs can be linked against LGPLed libraries. And again, there are lot of examples (Apache, Mozilla, Xorg, etc.) where this works. The page that you have referenced is of the GNU org, and even there it is hard to say that they are trying to encourage you to use the LGPL license. In any case, the main point is that When open IB windows was formed there was a general decision that it will use BSD license. If we Start having components with the LGPL this will break that decision, and therefore this requires some voting of the open IB organization. You are not going to maintain win-pthread32 as OpenIB component, but using this as third party. I think this should not be very different from using native windows thread dll (which I guess is not BSD too). I don't any LGPL issue here. Make sense? 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] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
This requires that the passive side be able to issue path record queries, but I think that it could work for static routes. A point was made to me that the remote side could be a TCA without query capabilities. Are you referring to SA query capabilities ? Would such a device just be expected to work without change in an IB routed environment anyway ? Yes I was referring to SA query capability, such as a path record query. Since the spec requires that the path information be provided by the active side, I think that such a device could work without change. (But it does mean that the active side has to provide some way to obtain the necessary information to put into a CM REQ, plus know what the remote router will do.) - 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: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
Well, the way I see it one can take code from the Linux part under the BSD licance and use it in The windows part. The otherway around seems fine to me but some say that since the windows BSD liscance Reqires that some text will always remain there, the other way around is not possibale. As I'm not an Expert in that erea I don't know who is right. Interesting. Where does this idea come from? AFAIK BSD license is well known to be GPL-compatible, so there should be no problem moving code in either direction. -- 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] [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]] Well, the way I see it one can take code from the Linux part under the BSD licance and use it in The windows part. The otherway around seems fine to me but some say that since the windows BSD liscance Reqires that some text will always remain there, the other way around is not possibale. As I'm not an Expert in that erea I don't know who is right. Interesting. Where does this idea come from? Maybe this? http://www.gnu.org/philosophy/bsd.html Note that openib license does not include the advertising clause. AFAIK BSD license is well known to be GPL-compatible, so there should be no problem moving code in either direction. -- 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] issues with compilation of ofed 1.2
On Thu, 2007-02-08 at 09:02 +0200, Moni Levy wrote: Doug, On 2/7/07, Yosef Etigin [EMAIL PROTECTED] wrote: 7. On RHAS5 beta 2, the setup requires sysfstuils-devel RPM which is not included in this distro. Can you please help us with that ? The value of the sysfsutils is far overshadowed by the value of libsysfs (and libsysfs is far more commonly used). So, in RHEL5, the rpm package names reflect this: libsysfs sysfsutils (I think, might be libsysfs-utils) libsysfs-devel It's all still there, just a different name. -- Moni -- Yosef Etigin Alex Tabachnik -- Doug Ledford [EMAIL PROTECTED] GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband 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] IB/ipoib_cm: fix up issues from code review
Quoting Roland Dreier [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/ipoib_cm: fix up issues from code review OK, I pulled this in and fixed it to build with the netdevice class_device-ectomy that just went upstream, and pushed it out on my for-2.6.21 branch like this. Thanks! -- 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 TRIVIAL] opensm: remove #ifdef __WIN__ in not shared file.
opensm/main.c is not shared by win OpenSM, and #ifdef __WIN__ is not
needed here.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/opensm/main.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/osm/opensm/main.c b/osm/opensm/main.c
index 69c940c..fa09360 100644
--- a/osm/opensm/main.c
+++ b/osm/opensm/main.c
@@ -65,10 +65,6 @@ static volatile unsigned int osm_usr1_flag = 0;
#define GUID_ARRAY_SIZE 64
#define INVALID_GUID (0xULL)
-#ifdef __WIN__
-#define block_signals()
-#define setup_signals()
-#else
static void mark_exit_flag(int signum)
{
if(!osm_exit_flag)
@@ -119,7 +115,6 @@ static void setup_signals()
#endif
pthread_sigmask(SIG_SETMASK, saved_sigset, NULL);
}
-#endif /* __WIN__ */
/**
**/
--
1.5.0.rc2.g11a3
___
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 TRIVIAL] osmtest: use more descriptive constant names
Use more descriptive constant names for osmtest flows.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
osm/osmtest/include/osmtest.h | 12
osm/osmtest/main.c| 20 ++--
osm/osmtest/osmtest.c | 22 +-
3 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/osm/osmtest/include/osmtest.h b/osm/osmtest/include/osmtest.h
index 39afbaf..13131dd 100644
--- a/osm/osmtest/include/osmtest.h
+++ b/osm/osmtest/include/osmtest.h
@@ -56,6 +56,18 @@
#include osmtest_base.h
#include osmtest_subnet.h
+enum OSMT_FLOWS {
+ OSMT_FLOW_ALL = 0,
+ OSMT_FLOW_CREATE_INVENTORY,
+ OSMT_FLOW_VALIDATE_INVENTORY,
+ OSMT_FLOW_SERVICE_REGISTRATION,
+ OSMT_FLOW_EVENT_FORWARDING,
+ OSMT_FLOW_STRESS_SA,
+ OSMT_FLOW_MULTICAST,
+ OSMT_FLOW_QOS,
+ OSMT_FLOW_TRAP,
+};
+
/s* OpenSM: Subnet/osmtest_opt_t
* NAME
* osmtest_opt_t
diff --git a/osm/osmtest/main.c b/osm/osmtest/main.c
index ca5805b..5f402b7 100644
--- a/osm/osmtest/main.c
+++ b/osm/osmtest/main.c
@@ -354,7 +354,7 @@ main( int argc,
opt.create = FALSE;
opt.mmode = 1;
opt.ignore_path_records = FALSE; /* Do path Records too */
- opt.flow = 0; /* run all validation tests */
+ opt.flow = OSMT_FLOW_ALL; /* run all validation tests */
strcpy(flow_name, All Validations);
strcpy( opt.file_name, osmtest.dat );
@@ -396,31 +396,31 @@ main( int argc,
if (!strcmp(c, optarg)) {
strcpy(flow_name, Create Inventory);
-opt.flow = 1;
+opt.flow = OSMT_FLOW_CREATE_INVENTORY;
} else if (!strcmp(v, optarg)) {
strcpy(flow_name, Validate Inventory);
-opt.flow = 2;
+opt.flow = OSMT_FLOW_VALIDATE_INVENTORY;
} else if (!strcmp(s, optarg)) {
strcpy(flow_name, Services Registration);
-opt.flow = 3;
+opt.flow = OSMT_FLOW_SERVICE_REGISTRATION;
} else if (!strcmp(e, optarg)) {
strcpy(flow_name, Event Forwarding);
-opt.flow = 4;
+opt.flow = OSMT_FLOW_EVENT_FORWARDING;
} else if (!strcmp(f, optarg)) {
strcpy(flow_name, Stress SA);
-opt.flow = 5;
+opt.flow = OSMT_FLOW_STRESS_SA;
} else if (!strcmp(m, optarg)) {
strcpy(flow_name, Multicast);
-opt.flow = 6;
+opt.flow = OSMT_FLOW_MULTICAST;
} else if (!strcmp(q, optarg)) {
strcpy(flow_name, QoS: VLArb and SLtoVL);
-opt.flow = 7;
+opt.flow = OSMT_FLOW_QOS;
} else if (!strcmp(t, optarg)) {
strcpy(flow_name, Trap 64/65);
-opt.flow = 8;
+opt.flow = OSMT_FLOW_TRAP;
} else if (!strcmp(a, optarg)) {
strcpy(flow_name, All Validations);
-opt.flow = 0;
+opt.flow = OSMT_FLOW_ALL;
} else {
printf( \nError: unknown flow %s\n,flow_name);
exit(2);
diff --git a/osm/osmtest/osmtest.c b/osm/osmtest/osmtest.c
index 3c16a6f..ce185ec 100644
--- a/osm/osmtest/osmtest.c
+++ b/osm/osmtest/osmtest.c
@@ -7948,7 +7948,7 @@ osmtest_run( IN osmtest_t * const p_osmt )
goto Exit;
}
- if( p_osmt-opt.flow == 1 )
+ if( p_osmt-opt.flow == OSMT_FLOW_CREATE_INVENTORY )
{
/*
* Creating an inventory file with all nodes, ports and paths
@@ -7965,7 +7965,7 @@ osmtest_run( IN osmtest_t * const p_osmt )
}
else
{
-if( p_osmt-opt.flow == 5 )
+if( p_osmt-opt.flow == OSMT_FLOW_STRESS_SA )
{
/*
* Stress SA - flood the it with queries
@@ -8030,7 +8030,8 @@ osmtest_run( IN osmtest_t * const p_osmt )
/*
* Run normal validition tests.
*/
- if (p_osmt-opt.flow == 0 || p_osmt-opt.flow == 2)
+ if (p_osmt-opt.flow == OSMT_FLOW_ALL ||
+ p_osmt-opt.flow == OSMT_FLOW_VALIDATE_INVENTORY)
{
/*
* Only validate the given inventory file
@@ -8056,7 +8057,7 @@ osmtest_run( IN osmtest_t * const p_osmt )
}
}
- if (p_osmt-opt.flow == 0)
+ if (p_osmt-opt.flow == OSMT_FLOW_ALL)
{
status = osmtest_wrong_sm_key_ignored( p_osmt );
if( status != IB_SUCCESS )
@@ -8069,7 +8070,8 @@ osmtest_run( IN osmtest_t * const p_osmt )
}
}
- if (p_osmt-opt.flow == 0 || p_osmt-opt.flow == 3)
+ if (p_osmt-opt.flow == OSMT_FLOW_ALL ||
+
Re: [openib-general] dapl broken for iWARP
On Wed, 2007-02-07 at 15:57 -0600, Steve Wise wrote: On Wed, 2007-02-07 at 14:02 -0600, Steve Wise wrote: Arlin, The OFED dapl code is assuming the responder_resources and initiator_depth passed up on a connection request event are from the remote peer. This doesn't happen for iWARP. In the current iWARP specifications, its up to the application to exchange this information somehow. So these are defaulting to 0 on the server side of any dapl connection over iWARP. This is a fairly recent change, I think. We need to come up with some way to deal with this for OFED 1.2 IMO. The IWCM could set these to the device max values for instance. Steve. There is a slight problem with all this. There are no device attributes currently for ORD and IRD. The ammasso driver maps these to max_qp_rd_atom (IRD) and max_qp_init_rd_atom(ORD). But this is screwy. We need new attribute for these. For OFED 1.2, I think I should just have the IWCM set them to 8. The only RNIC in ofed is cxgb3 and it supports 8... 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
Re: [openib-general] Problem is routing CM REQ
Looking at the problem more, I think that the issue extends to the remote port LID as well. My expectation with a local path record query is that the SLID is the local port, and the DLID is the local router. This should be sufficient for one-way UD traffic, but for connected traffic we still need to discover the remote router and remote port LIDs. Given a path record query for: SGID - local DGID - remote What would be the SLID and DLID? And if the query is reversed, such that: SGID - remote DGID - local Are the SLID/DLID values simply reversed? What if the DGID in the second case were a multicast GID? What does the SLID become in this case? - 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] Problem is routing CM REQ was: Use a GRH when appropriate for unicast packets
On Thu, 2007-02-08 at 17:02, Sean Hefty wrote: This requires that the passive side be able to issue path record queries, but I think that it could work for static routes. A point was made to me that the remote side could be a TCA without query capabilities. Are you referring to SA query capabilities ? Would such a device just be expected to work without change in an IB routed environment anyway ? Yes I was referring to SA query capability, such as a path record query. Since the spec requires that the path information be provided by the active side, I think that such a device could work without change. (But it does mean that the active side has to provide some way to obtain the necessary information to put into a CM REQ, plus know what the remote router will do.) It also means it needs to be able to put a GRH in on the sending side. Not sure that is free in implementations as you have been noting for OpenIB recently. -- Hal - 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] please pull for 2.6.21: fix + add IB multicast support
I merged the increment port number and remove redundant '_wq' patches from git.openfabrics.org/~shefty/scm/rdma-dev.git for-roland I plan to review to multicast stuff next week and I hope to merge it for 2.6.21. Or, have you or anyone else at Voltaire read over the code in addition to using it? Do you see anything that should be cleaned up? - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/5] iw_cxgb3 - misc cleanup and fixes
OK, I've pulled the cxgb3 stuff into a single commit in my for-2.6.21 branch. I took the liberty of cleaning up some sparse warnings, etc. There's still a few other obvious things to fix up: drivers/infiniband/hw/cxgb3/iwch_ev.c:102:6: warning: symbol 'iwch_ev_disp atch' was not declared. Should it be static? Rather than putting an extern in iwch.c, please put a proper definition in an appropriate header file included from iwch.c. Also I agree with MST, I would like to see the core/ subdirectory die completely. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/5] iw_cxgb3 - misc cleanup and fixes
On Thu, 2007-02-08 at 16:26 -0800, Roland Dreier wrote: OK, I've pulled the cxgb3 stuff into a single commit in my for-2.6.21 branch. I took the liberty of cleaning up some sparse warnings, etc. There's still a few other obvious things to fix up: drivers/infiniband/hw/cxgb3/iwch_ev.c:102:6: warning: symbol 'iwch_ev_disp atch' was not declared. Should it be static? Rather than putting an extern in iwch.c, please put a proper definition in an appropriate header file included from iwch.c. ok. Also I agree with MST, I would like to see the core/ subdirectory die completely. ok ok...I'll kill the subdir... ___ 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/5] iw_cxgb3 - misc cleanup and fixes
Oh yeah -- Steve, please keep sending cleanup patches based on my tree now. I'm planning on asking Linus to merge what's in for-2.6.21 in the next couple of days, but there's still more than a week before the merge window closes, and even after the merge window closes I'll still accept fixes/cleanups for stuff already upstream. And here's what I have pending in for-2.6.21 so far: Ahmed S. Darwish (1): IB/core: Use ARRAY_SIZE macro for mandatory_table Akinobu Mita (1): IB/ehca: Fix memleak on module unloading David Howells (1): IB/mthca: Work around gcc bug on sparc64 Michael S. Tsirkin (1): IPoIB: Connected mode experimental support Roland Dreier (1): IB/mthca: Use correct structure size in call to memset() Sean Hefty (2): RDMA/cma: Increment port number after close to avoid re-use IB: Remove redundant _wq from workqueue names Steve Wise (1): RDMA/cxgb3: Add driver for Chelsio T3 Rnic ___ 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] ofed_1_2 - SLES9SP3 Backport -IWCM workaroundfor ip_dev_find() bug.
Michael,
From your email, it sounded like you would regression test this. Is it
ready to pull in?
Thanks!
Steve.
On Tue, 2007-02-06 at 17:39 -0600, Steve Wise wrote:
Here it is (only tested with rping over iWARP on sles9sp3):
xxx_ip_dev_find() must use scope HOST.
From: Steve Wise [EMAIL PROTECTED]
Function xxx_ip_dev_find(RT_SCOPE_LINK) returns the wrong interface on
some kernels. The correct scope is RT_SCOPE_HOST.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
.../backport/2.6.11/include/linux/inetdevice.h |2 +-
.../backport/2.6.11_FC4/include/linux/inetdevice.h |2 +-
.../backport/2.6.12/include/linux/inetdevice.h |2 +-
.../backport/2.6.13/include/linux/inetdevice.h |2 +-
.../2.6.13_suse10_0_u/include/linux/inetdevice.h |2 +-
.../backport/2.6.14/include/linux/inetdevice.h |2 +-
.../backport/2.6.15/include/linux/inetdevice.h |2 +-
.../2.6.15_ubuntu606/include/linux/inetdevice.h|2 +-
.../backport/2.6.16/include/linux/inetdevice.h |2 +-
.../backport/2.6.17/include/linux/inetdevice.h |2 +-
.../2.6.5_sles9_sp3/include/linux/inetdevice.h |2 +-
.../backport/2.6.9_U2/include/linux/inetdevice.h |2 +-
.../backport/2.6.9_U3/include/linux/inetdevice.h |2 +-
.../backport/2.6.9_U4/include/linux/inetdevice.h |2 +-
14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel_addons/backport/2.6.11/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.11/include/linux/inetdevice.h
index 7244487..2d3c50f 100644
--- a/kernel_addons/backport/2.6.11/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.11/include/linux/inetdevice.h
@@ -13,7 +13,7 @@ static inline struct net_device *xxx_ip_
read_lock(dev_base_lock);
for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
if (ip == addr) {
dev_hold(dev);
break;
diff --git a/kernel_addons/backport/2.6.11_FC4/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.11_FC4/include/linux/inetdevice.h
index 7244487..2d3c50f 100644
--- a/kernel_addons/backport/2.6.11_FC4/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.11_FC4/include/linux/inetdevice.h
@@ -13,7 +13,7 @@ static inline struct net_device *xxx_ip_
read_lock(dev_base_lock);
for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
if (ip == addr) {
dev_hold(dev);
break;
diff --git a/kernel_addons/backport/2.6.12/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.12/include/linux/inetdevice.h
index 7244487..2d3c50f 100644
--- a/kernel_addons/backport/2.6.12/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.12/include/linux/inetdevice.h
@@ -13,7 +13,7 @@ static inline struct net_device *xxx_ip_
read_lock(dev_base_lock);
for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
if (ip == addr) {
dev_hold(dev);
break;
diff --git a/kernel_addons/backport/2.6.13/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.13/include/linux/inetdevice.h
index 7a32313..fd0aa36 100644
--- a/kernel_addons/backport/2.6.13/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.13/include/linux/inetdevice.h
@@ -11,7 +11,7 @@ static inline struct net_device *xxx_ip_
read_lock(dev_base_lock);
for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
if (ip == addr) {
dev_hold(dev);
break;
diff --git
a/kernel_addons/backport/2.6.13_suse10_0_u/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.13_suse10_0_u/include/linux/inetdevice.h
index 7a32313..fd0aa36 100644
--- a/kernel_addons/backport/2.6.13_suse10_0_u/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.13_suse10_0_u/include/linux/inetdevice.h
@@ -11,7 +11,7 @@ static inline struct net_device *xxx_ip_
read_lock(dev_base_lock);
for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
if (ip == addr) {
dev_hold(dev);
break;
diff --git a/kernel_addons/backport/2.6.14/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.14/include/linux/inetdevice.h
index 7a32313..fd0aa36 100644
---
Re: [openib-general] Unknown SMP Recv
Hi, I think I have found the problem. It is the timeout parameter on the umad_send function. How exactly I have to handle this parameter? It seems to be that it shoult be zero if there is no response exspected. But what value should it be if there is a response expected. In a test I used zero for SubnGetResp packets because there shouldn't be more packets and 100 for SubnGet or SubnSet. But if the router is stressed the umad_send function broke down and give an error -5 every thiertieth packet. Any idea or advice? Thanks Michael ___ 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] dapl broken for iWARP
For OFED 1.2, I think I should just have the IWCM set them to 8. The only RNIC in ofed is cxgb3 and it supports 8... Steve, If we can create the new attributes for RNICs, it seems like would be better to agree on the mapping of IRD/ORD to IB parameters than it would be to limit these parameters to 8. That number seems a bit low. Bob ___ 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] dapl broken for iWARP
On Thu, 2007-02-08 at 19:19 -0600, Bob Sharp wrote: For OFED 1.2, I think I should just have the IWCM set them to 8. The only RNIC in ofed is cxgb3 and it supports 8... Steve, If we can create the new attributes for RNICs, it seems like would be better to agree on the mapping of IRD/ORD to IB parameters than it would be to limit these parameters to 8. That number seems a bit low. Hey Bob, This is for the OFED 1.2 release only and its too late to be adding new features methinks since we're at feature freeze. For the upstream kernel (ie 2.6.21) we can define the attributes. Bob ___ 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] dapl broken for iWARP
For OFED 1.2, I think I should just have the IWCM set them to 8. The only RNIC in ofed is cxgb3 and it supports 8... Steve, If we can't create the new attributes for RNICs, it seems like it would be better to agree on the mapping of IRD/ORD to IB parameters than it would be to limit these parameters to 8. That number seems a bit low. Hey Bob, This is for the OFED 1.2 release only and its too late to be adding new features methinks since we're at feature freeze. For the upstream kernel (ie 2.6.21) we can define the attributes. I figured as much. So lets just go with your Ammasso mapping of IRD/ORD to the IB parameters that RNICs don't use for now. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] RDMA/iwcm: Bugs in cm_conn_req_handler()
Roland, Yes, we will do some arm wrestling today :) thanks, KK Roland Dreier [EMAIL PROTECTED] wrote on 02/09/2007 05:20:42 AM: Hmm, Steve likes it, Tom doesn't. Can you guys arm wrestle or something and tell me if this patch is correct or not? - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Unknown SMP Recv
On Thu, 2007-02-08 at 19:39, Michael Arndt wrote: Hi, I think I have found the problem. It is the timeout parameter on the umad_send function. How exactly I have to handle this parameter? It seems to be that it shoult be zero if there is no response exspected. But what value should it be if there is a response expected. In a test I used zero for SubnGetResp packets because there shouldn't be more packets and 100 for SubnGet or SubnSet. But if the router is stressed the umad_send function broke down and give an error -5 every thiertieth packet. Any idea or advice? umad_send takes the timeout in msec. 100 msec is too short. Try something on the order of seconds. Note also that negative 'timeout_ms' value makes the kernel wait for the reply forever. -- Hal Thanks Michael ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] RDMA/iwcm: Bugs in cm_conn_req_handler()
BTW, while looking at iwcm.c, I noticed the following highly dubious
code for the first time:
static int iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
{
int ret = 0;
BUG_ON(atomic_read(cm_id_priv-refcount)==0);
if (atomic_dec_and_test(cm_id_priv-refcount)) {
BUG_ON(!list_empty(cm_id_priv-work_list));
if (waitqueue_active(cm_id_priv-destroy_comp.wait)) {
BUG_ON(cm_id_priv-state !=
IW_CM_STATE_DESTROYING);
BUG_ON(test_bit(IWCM_F_CALLBACK_DESTROY,
cm_id_priv-flags));
ret = 1;
}
complete(cm_id_priv-destroy_comp);
}
return ret;
}
The test of waitqueue_active on destroy_comp.wait looks really bad for
two reasons: first, it is relying on an internal implementation detail
of struct completion that really shouldn't be used by generic code.
And second, it seems to me that this doesn't even work right, since
there is a race something like the following:
iw_destroy_cm_id():
destroy_cm_id(cm_id); // still 1 ref left
cm_work_handler():
if (iwcm_deref_id()) // drop last ref
return;
// no one waiting yet, doesn't
// return, but destroy_comp is
// signaled
wait_for_completion(cm_id_priv-destroy_comp);
// destroy_comp is signaled, proceed
kfree(cm_id_priv);
// continue using cm_id_priv
// OOPS
I don't understand this code well enough for the fix to be obvious.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Problem is routing CM REQ
On Thu, Feb 08, 2007 at 03:43:24PM -0800, Sean Hefty wrote: Looking at the problem more, I think that the issue extends to the remote port LID as well. My expectation with a local path record query is that the SLID is the local port, and the DLID is the local router. This should be sufficient for one-way UD traffic, but for connected traffic we still need to discover the remote router and remote port LIDs. Given a path record query for: SGID - local DGID - remote What would be the SLID and DLID? And if the query is reversed, such that: SGID - remote DGID - local Are the SLID/DLID values simply reversed? I have a follow up question to this.. With CM how is the SL for each side determined? I'm looking through the code here and it looks like the SL of the active side is passed in the REQ to the passive side (ie both sides are the same) But cma_query_ib_route does not set the reversible bit when it asks for the path. If you don't set the reversible bit isn't it necessary to make a 2nd path query to get the reverse path's SL? [Path responses without the reversible bit set are actually simplex paths and reversing them probably will run into SL2VL mapping tables that cause the packets to be dropped ie o7-8] Infact, to get an optimal path aren't 3 path records required: 1) A reversible path from active to passive from the CM GMPs (required by C12-5.1.3) 2) An optimal non-reversible path from active to passive 3) An optimal non-reversible path from passive to active Jason ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] RDMA/iwcm: Bugs in cm_conn_req_handler()
Regarding the race - can this and the other problem (of
using internal data-structure) both be taken care of by
changing iw_deref_id to return 1 if atomic_dec_and_test
finds the last reference ? Then the waitqueue_active()
code can be removed, just do the completion (reaching
here implies that someone is in the middle of
iw_destroy_cm_id).
The question is what is the issue if we return 1 even if
no one is waiting in iw_destroy_cm_id() and which results
in cm_work_handler() returning out ?
thanks,
- KK
BTW, while looking at iwcm.c, I noticed the following highly dubious
code for the first time:
static int iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
{
int ret = 0;
BUG_ON(atomic_read(cm_id_priv-refcount)==0);
if (atomic_dec_and_test(cm_id_priv-refcount)) {
BUG_ON(!list_empty(cm_id_priv-work_list));
if (waitqueue_active(cm_id_priv-destroy_comp.wait)) {
BUG_ON(cm_id_priv-state != IW_CM_STATE_DESTROYING);
BUG_ON(test_bit(IWCM_F_CALLBACK_DESTROY,
cm_id_priv-flags));
ret = 1;
}
complete(cm_id_priv-destroy_comp);
}
return ret;
}
The test of waitqueue_active on destroy_comp.wait looks really bad for
two reasons: first, it is relying on an internal implementation detail
of struct completion that really shouldn't be used by generic code.
And second, it seems to me that this doesn't even work right, since
there is a race something like the following:
iw_destroy_cm_id():
destroy_cm_id(cm_id); // still 1 ref left
cm_work_handler():
if (iwcm_deref_id()) // drop last ref
return;
// no one waiting yet, doesn't
// return, but destroy_comp is
// signaled
wait_for_completion(cm_id_priv-destroy_comp);
// destroy_comp is signaled, proceed
kfree(cm_id_priv);
// continue using cm_id_priv
// OOPS
I don't understand this code well enough for the fix to be obvious.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/5] iw_cxgb3 - misc cleanup and fixes
Also I agree with MST, I would like to see the core/ subdirectory die completely. ok ok...I'll kill the subdir... It's not just the directory BTW. Stuff like building completions in t3_cqe format and then reformatting to ib_wc seems to be much more confusing (and some of it is actually on datapath). Same goes for t3_wq and I suspect everything else defined in cxio_wr.h - please, use the native types from include/rdma/. Having to wade through 3 driver-specific layers of abstractions just because I want to for example change API in ib_verbs.h and need to update all drivers will be very taxing. I understand your design calls for 2 layers, but at least the API exposed by code in drivers/net is fairly small, while cxio_wr.h declares 27 structures which seem to just duplicate ib_verbs.h. -- 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] ofed_1_2 - SLES9SP3 Backport-IWCM workaroundfor ip_dev_find() bug.
Quoting Steve Wise [EMAIL PROTECTED]: Subject: Re: [openib-general] [PATCH] [RFC] ofed_1_2 - SLES9SP3 Backport-IWCM workaroundfor ip_dev_find() bug. Michael, From your email, it sounded like you would regression test this. Not yet, we had lab restructuring - hopefully next week. -- 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 0/5] iw_cxgb3 - misc cleanup and fixes
And here's what I have pending in for-2.6.21 so far: What about the mthca memory registration patches? I thought they are on their way. Should I repost? -- 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
