Re: [OMPI devel] RDMA pipeline

Actually, it restores the original behavior. The RDMA operations were pipelined before the r15247 commit, independent of the fact that they had mpool or not. We were actively using this behavior in the message logging framework to hide the cost of the local storage of the payload, and we

Re: [OMPI devel] RDMA pipeline

On Tue, Feb 19, 2008 at 02:13:30PM -0500, George Bosilca wrote: > Few days ago during some testing I realize that the RDMA pipeline was > disabled for MX and Elan (I didn't check for the others). A quick look > into the source code, pinpointed the problem into the pml_ob1_rdma.c > file, and

[OMPI devel] RDMA pipeline

Few days ago during some testing I realize that the RDMA pipeline was disabled for MX and Elan (I didn't check for the others). A quick look into the source code, pinpointed the problem into the pml_ob1_rdma.c file, and it seems that the problem was introduced by commit 15247. The problem

Re: [OMPI devel] PLPA ready?

Jeff, In the patch you sent the variables: num_processors, num_sockets and num_cores are lost outside the paffinity framework. I need those in the ODLS framework. what do think about the attached patch? Sharon. 2008/2/19 Jeff Squyres : > $%@#$% Sorry. > > I saw that and

Re: [OMPI devel] PLPA ready?

I am guessing it will not messing us up because these are the functions that Solaris doesn't really implement yet, right? Last time I check we are still hunting for some stable interfaces in Solaris to implement them. Terry Dontje wrote: Jeff Squyres wrote: $%@#$% Sorry. I saw that and

Re: [OMPI devel] PLPA ready?

Will do. I stress that it *might* be worthwhile -- I think it at least partially depends on what Voltaire does and whether they think it should change (since they're the first ones using the paffinity API in a meaningful way). If we want to change it, it would probably be good to do so

Re: [OMPI devel] PLPA ready?

Jeff, The new PLPA fails in compilation. there is a need to change the paffinity API's: 1. max_processor_id with one parameter --> get_processor_info with 2 parameters. 2. max_socket with one parameter --> get_socket_info with 2 parameters. 3. max_core with 2 parameters --> get_core_info with 3