[Pvfs2-developers] Ready to test MX - how to start?

[kyle schochenmaier]

On Dec 17, 2006, at 2:36 PM, Scott Atchley wrote:

> 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?
>

You shouldnt need disks IO to test whether or not your port works.   
Most of the critical problems that you will run into will be on the  
BMI layer, which doesnt really manage the disks.  The only thing  
we've ever 'needed' disks to test for in the past is fine tuning for  
these new 10Gb+ hardwares.  If someone wants to send me the MX  
hardware to test on fast disks I'm sure I could convince someone here  
to let us test it, but I dont think that'll be an option.  Good luck.
Netpipe proved to be very useful in testing/reproducing some of our  
problems with the IB code.
I can get you an early release once you get the MX stuff to a point  
where you can do pvfs2-cp on it if you're interested.

+=Kyle

>> 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
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>
> !DSPAM:4585ab91217681542719951!
>