Hi all, I am ready to start testing MX support.
What do I need to do to include bmi_mx in the configure and make process? Would it be easier to work with a cvs checkout or a release tarball?
As for testing, I do not have disks fast enough to stress Myrinet-2000 (2Gb/s) NICs let alone Myri-10G NICs. In other emails, these options have been mentioned. Which makes most sense (least amount of coding, compiling issues, etc.)? Do they require disk IO?
We have a flow method called 'flowproto-dump-offsets', which will dump offset-length pairs. the problem is that the method isn't used very much, and it has not kept up with some of the API changes and no longer compiles. If that sort of thing sounds useful to you, we might be able to get it back into shape. There are some BMI tests in the test/io/bmi directory which will stress just the BMI layer. Those tests might also need some manual coaxing to exercise bmi_mx (the gm versions hard-code 'bmi_gm' into the call to BMI_Initialize, for example).
There's also Julian's Trove 'TAS' implementation, which he's got sitting in a branch ready to be merged. I had him update it so it works with the new trove-method stuff I committed, so maybe it makes sense to merge that to trunk before a next release? Its probably going to be easier to do that than try to figure out exactly why dump-offsets isn't working.
If anyone wants to look at a tarball of what I have so far, let me know. It is only about 2300 LOC. I still need to add more error checking, convert to PVFS-style error reporting, and cleanup of peer state when a peer has restarted.
Scott _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
