Re: [OMPI devel] vampir trace - additional compiler options

[Jeff Squyres]

(moving discussion to public devel list)

Thanks Andreas!

I talked through a bunch of details with Brian a bit about VT  
integration on the phone yesterday; here's what we came up with:


- Let's bring the code in via the normal SVN 3rd party methods  
(https://svn.open-mpi.org/trac/ompi/wiki/VendorImport) and put it in  
ompi/tracing/vampirtrace.  We can put a "glue" Makefile.am in that  
directory (and possibly a configure.m4 for all the configury stuff  
that we'll need in the top-level OMPI configure -- details TBD), and  
put the actual VT code one level below this.  This strategy allows for:


  - Bringing in other tracing tools someday
  - A descriptive directory name so that it's easy to know what's there

- It turns out that "vtcc --showme:*" isn't going to be sufficient  
(sorry about that :-( ) because it won't work in cross-compiling  
scenarios.  So we'll either need a way to get these flags directly  
(either easily snarf them out of a file or run a script that will get  
them for us) or we'll simply have mpicc-vt call vtcc (a brianstorm  
from Brian).  Need to experiment with this to know if it'll work, but  
it might be the easiest/best way.  I'll let you know.


- One thing that I did not think of ahead of time is a good way to  
know that VT has decided not to build itself (e.g., its configure  
fails).  We'll need to ensure that if the VT configure aborts, it  
doesn't abort the top-level OMPI configure.


I'll probably have time to start on this next week, but may need some  
help from you guys.I'll keep you posted.



On Jul 3, 2007, at 10:59 AM, Andreas Knüpfer wrote:


Hi Jeff, hi All,

we discussed the question how the new compiler wrapper can find out  
about
VampirTrace's additional compiler or linker options. This can be  
done with


# > vtcc -vt:showme_compile
# > vtcc -vt:showme_link

It works the same way for vtcxx, vtf90 etc. if present.

btw: You can get the latest version of the VampirTrace tarball  
including OTF

(open trace format) at http://www.tu-dresden.de/zih/vampirtrace/


Andreas


--
Dipl. Math. Andreas Knuepfer,
Center for Information Services and
High Performance Computing (ZIH), TU Dresden,
Willersbau A114, Zellescher Weg 12, 01062 Dresden
phone +49-351-463-38323, fax +49-351-463-37773


--
Jeff Squyres
Cisco Systems

Re: [OMPI devel] extracting MPI message tag at the btl level

[Karol Mroz]

I wanted to post another followup to this message.

I realize that the design philosophy implies that the BTL should operate 
at a level of abstraction where it merely shuttles bytes around. 
However, my recent experience suggests that it might actually be useful 
to have the ability to selectively query the context in which this data 
is being used, such as message tags, contexts, etc.


In order to have this, though, I'd need to be able to fetch the context 
and tag information from the header when it arrives at the BTL. This 
data appears to have been transformed somehow when it gets to that 
layer, though, and I'm trying to figure out how. Has something arcane 
been done to this data aside from switching byte ordering?


Thanks,
Karol

George Bosilca wrote:
  

Karol,

There is no way to know the MPI tag at the BTL level. The BTL is 
protocol agnostic, it only moves bytes around (BTL = Byte Transport 
Layer). Moreover, the BTLs can be (and are) used by different PML, 
each of them supporting a different protocol.


Now, let talk specifically about the OB1 PML. The first X bytes 
contain a message header, but this message header differ based on the 
protocol used to transmit the message. There are multiple protocols: 
eager, send/recv, RDMA. If you look in ompi/mca/pml/ob1/pml_ob1_hdr.h 
you will see the different types of headers used by the OB1 PML. 
However, do not use this file in the BTL, as the BTL is PML agnostic.


  Thanks,
george.

On Jul 2, 2007, at 4:56 PM, Karol Mroz wrote:



Good morning everyone. I had a question about obtaining the message tag
from the iovec array in mca_btl_sctp_frag_t* frag from within the
mca_btl_tcp_frag_send() function. If I understand correctly, the first X
bytes in the first iovec entry contain message header information in the
form of an mca_pml_ob1_match_hdr_t struct that contains a hdr_tag field.
When I extract this, I get a number that resembles an address.
Dereferencing this gives, from what I can tell, an incorrect value and
passing the value into ntohl() etc brings me no closer. There is
probably something basic I'm overlooking... any help would be 
appreciated.


Thanks,
Karol

--Karol Mroz
km...@cs.ubc.ca

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel




--
Karol Mroz
km...@cs.ubc.ca