[ewg] Review of OFA Logo NFS/RDMA testing

[Hal Rosenstock]

On 4/11/2014 10:30 AM, Hal Rosenstock wrote:
> On 4/11/2014 10:29 AM, Rimmer, Todd wrote:
>> I think it is wise to include testing with a variety of SMs and SM versions.
>>
>> Procedurally, it would be recommended to stop the SMs, reboot the fabric, start the new SMs.
> 
> I agree and wasn't suggesting otherwise. I was only talking about
> failover/handover without the full process you describe above.

Note that even changing between different "versions" of OpenSM can be
problematic if they support different features which is likely the case
when OpenSM is in embedded switch or some other vendor product v. some
host based OpenSM.

-- Hal

> 
> -- Hal
> 
>> Todd Rimmer
>> DCSG Architecture
>> Voice: 610-312-2152     Fax: 610-312-2233
>> Todd.Rimmer at intel.com
>>
>>
>>> -----Original Message-----
>>> From: ewg-bounces at lists.openfabrics.org [mailto:ewg-
>>> bounces at lists.openfabrics.org] On Behalf Of Edward Mossman
>>> Sent: Wednesday, April 09, 2014 2:54 PM
>>> To: Chuck Lever
>>> Cc: Bob Noseworthy; ewg at lists.openfabrics.org; Shirley Ma
>>> Subject: Re: [ewg] Review of OFA Logo NFS/RDMA testing
>>>
>>> Chuck,
>>>
>>> Thanks for taking the time to look through our test plan and provide
>>> suggestions. I will bring these suggestions to the next IWG meeting and we
>>> will vote on whether to include some or all in the test plan.
>>>
>>> Previously we were executing our InfiniBand tests with OpenSM as the
>>> Master SM, then disabling OpenSM and turning on the Subnet Managers
>>> that are included in our InfiniBand switches. This was meant to expose any
>>> interoperability issues with, say, a Subnet Manager on an Intel switch
>>> controlling a fabric comprised of Mellanox and Intel HCAs. We have since
>>> scaled back and only require a device to be interoperable when using
>>> OpenSM.
>>>
>>> Thanks,
>>> Edward
>>>
>>> On Mon, 7 Apr 2014, Chuck Lever wrote:
>>>
>>>> Hi Edward-
>>>>
>>>> After reviewing your NFS/RDMA Logo test plan
>>> (https://iol.unh.edu/ofatestplan), I had some thoughts.
>>>>
>>>> No "vers=" mount option is specified on your clients, thus only one NFS
>>> version is tested.
>>>>
>>>> The default NFS version depends on the client version and server
>>> configuration, so it is better to set the NFS version explicitly. I recommend
>>> adding a specific "vers=" setting on your scripted mount commands, and run
>>> the cthon tests at least three times (with a umount/mount between each
>>> run): once for vers=2, once for vers=3, and once for vers=4 (4.0). Eventually
>>> 4.1 and 4.2 should be added when Linux NFS/RDMA is updated to support
>>> those minor versions. For now the two critical NFS versions are NFSv3 and
>>> NFSv4.0.
>>>>
>>>> Since you have a broad array of hardware in your test harness, that would
>>> be an opportunity for more extensive platform interoperability testing. The
>>> following areas might be interesting and appropriate.
>>>>
>>>> 	. 32-bit v. 64-bit
>>>> 	. 4KB pages v. other page sizes
>>>> 	. Little v. big endian
>>>>
>>>> Simply ensure your test matrix includes these combinations of clients and
>>> servers. Power will already get you large page sizes, for example.
>>>>
>>>> I am curious about the test plan's requirement to run your NFS/RDMA tests
>>> using every SM you have in your lab. Can you elaborate on that
>>> requirement?
>>>>
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Edward Mossman
>>> UNH-IOL OFILG
>>> emossman at iol.unh.edu
>> _______________________________________________
>> ewg mailing list
>> ewg at lists.openfabrics.org
>> http://lists.openfabrics.org/mailman/listinfo/ewg
>>
>