[uDAPL] replaced with DaplTest_how_2.txt
authorstansmith <stansmith@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Tue, 3 Apr 2007 04:43:16 +0000 (04:43 +0000)
committerstansmith <stansmith@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Tue, 3 Apr 2007 04:43:16 +0000 (04:43 +0000)
git-svn-id: svn://openib.tc.cornell.edu/gen1/trunk@622 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86

ulp/dapl/test/udapl/dapltest/dapltest.txt [deleted file]

diff --git a/ulp/dapl/test/udapl/dapltest/dapltest.txt b/ulp/dapl/test/udapl/dapltest/dapltest.txt
deleted file mode 100644 (file)
index 7a84396..0000000
+++ /dev/null
@@ -1,296 +0,0 @@
-\r
-NAME\r
-\r
-    dapltest    - test for the Direct Access Programming Library (DAPL)\r
-\r
-DESCRIPTION\r
-\r
-    Dapltest is a set of tests developed to exercise, characterize,\r
-    and verify the DAPL interfaces during development and porting.\r
-    At least two instantiations of the test must be run.  One acts\r
-    as the server, fielding requests and spawning server-side test\r
-    threads as needed.  Other client invocations connect to the\r
-    server and issue test requests.\r
-\r
-    The server side of the test, once invoked, listens continuously\r
-    for client connection requests, until quit or killed.  Upon\r
-    receipt of a connection request, the connection is established,\r
-    the server and client sides swap version numbers to verify that\r
-    they are able to communicate, and the client sends the test\r
-    request to the server.  If the version numbers match, and the\r
-    test request is well-formed, the server spawns the threads\r
-    needed to run the test before awaiting further connections.\r
-\r
-USAGE\r
-\r
-    dapltest [ -f script_file_name ]\r
-             [ -T S|Q|T|P|L ] [ -D device_name ] [ -d ] [ -R HT|LL|EC|PM|BE ]\r
-\r
-    With no arguments, dapltest runs as a server using default values,\r
-    and loops accepting requests from clients.  The -f option allows\r
-    all arguments to be placed in a file, to ease test automation.\r
-    The following arguments are common to all tests:\r
-\r
-    [ -T S|Q|T|P|L ]    Test function to be performed:\r
-                            S   - server loop\r
-                            Q   - quit, client requests that server\r
-                                  wait for any outstanding tests to\r
-                                  complete, then clean up and exit\r
-                            T   - transaction test, transfers data between \r
-                                  client and server\r
-                            P   - performance test, times DTO operations\r
-                            L   - limit test, exhausts various resources,\r
-                                  runs in client w/o server interaction\r
-                        Default: S\r
-\r
-    [ -D device_name ]  Specifies the name of the device (interface adapter).\r
-                        Default: host-specific, look for DT_MdepDeviceName\r
-                                 in dapl_mdep.h\r
-\r
-    [ -d ]              Enables extra debug verbosity, primarily tracing\r
-                       of the various DAPL operations as they progress.\r
-                       Repeating this parameter increases debug spew.\r
-                       Errors encountered result in the test spewing some\r
-                       explanatory text and stopping; this flag provides\r
-                       more detail about what lead up to the error.\r
-                        Default: zero\r
-\r
-    [ -R BE ]           Indicate the quality of service (QoS) desired.\r
-                        Choices are:\r
-                            HT  - high throughput\r
-                            LL  - low latency\r
-                            EC  - economy (neither HT nor LL)\r
-                            PM  - premium\r
-                            BE  - best effort\r
-                        Default: BE\r
-/-p\r
-\r
-USAGE - Quit test client\r
-\r
-    dapltest [Common_Args] [ -s server_name ]\r
-\r
-    Quit testing (-T Q) connects to the server to ask it to clean up and\r
-    exit (after it waits for any outstanding test runs to complete).\r
-    In addition to being more polite than simply killing the server,\r
-    this test exercises the DAPL object teardown code paths.\r
-    There is only one argument other than those supported by all tests:\r
-\r
-    -s server_name      Specifies the name of the server interface.\r
-                        No default.\r
-\r
-\r
-USAGE - Transaction test client\r
-\r
-    dapltest [Common_Args] [ -s server_name ]\r
-             [ -t threads ] [ -w endpoints ] [ -i iterations ] [ -Q ] \r
-             [ -V ] [ -P ] OPclient OPserver [ op3, \r
-\r
-    Transaction testing (-T T) transfers a variable amount of data between \r
-    client and server.  The data transfer can be described as a sequence of \r
-    individual operations; that entire sequence is transferred 'iterations' \r
-    times by each thread over all of its endpoint(s).\r
-\r
-    The following parameters determine the behavior of the transaction test:\r
-\r
-    -s server_name      Specifies the name of the server interface.\r
-                        No default.\r
-\r
-    [ -t threads ]      Specify the number of threads to be used.\r
-                        Default: 1\r
-\r
-    [ -w endpoints ]    Specify the number of connected endpoints per thread.\r
-                        Default: 1\r
-\r
-    [ -i iterations ]   Specify the number of times the entire sequence\r
-                        of data transfers will be made over each endpoint.\r
-                        Default: 1000\r
-\r
-    [ -Q ]              Funnel completion events into a CNO.\r
-                       Default: use EVDs\r
-\r
-    [ -V ]              Validate the data being transferred.\r
-                       Default: ignore the data\r
-\r
-    [ -P ]             Turn on DTO completion polling\r
-                       Default: off\r
-\r
-    OP1 OP2 [ OP3, ... ]\r
-                        A single transaction (OPx) consists of:\r
-\r
-                        server|client   Indicates who initiates the\r
-                                        data transfer.\r
-\r
-                        SR|RR|RW        Indicates the type of transfer:\r
-                                        SR  send/recv\r
-                                        RR  RDMA read\r
-                                        RW  RDMA write\r
-                        Defaults: none\r
-\r
-                        [ seg_size [ num_segs ] ]\r
-                                        Indicates the amount and format\r
-                                        of the data to be transferred.\r
-                                        Default:  4096  1\r
-                                                  (i.e., 1 4KB buffer)\r
-\r
-                        [ -f ]          For SR transfers only, indicates\r
-                                        that a client's send transfer\r
-                                        completion should be reaped when\r
-                                        the next recv completion is reaped.\r
-                                       Sends and receives must be paired\r
-                                       (one client, one server, and in that\r
-                                       order) for this option to be used.\r
-\r
-    Restrictions:  due to the flow control algorithm used by the\r
-    transaction test, there must be at least one SR OP for both the\r
-    client and the server.  Requesting data validation (-V) causes the\r
-    test to automatically append three OPs to those specified, to\r
-    provide synchronization points during each iteration, at which all\r
-    user-specified transaction buffers are checked.  These three appended\r
-    operations satisfy the "one SR in each direction" requirement.\r
-    The transaction OP list is printed out if -d is supplied.\r
-\r
-USAGE - Performance test client\r
-\r
-    dapltest [Common_Args] -s server_name [ -m p|b ]\r
-             [ -i iterations ] [ -p pipeline ] OP\r
-\r
-    Performance testing (-T P) times the transfer of an operation.\r
-    The operation is posted 'iterations' times.\r
-\r
-    The following parameters determine the behavior of the transaction test:\r
-\r
-    -s server_name      Specifies the name of the server interface.\r
-                        No default.\r
-\r
-    -m b|p             Used to choose either blocking (b) or polling (p)\r
-                        Default: blocking (b)\r
-\r
-    [ -i iterations ]   Specify the number of times the entire sequence\r
-                        of data transfers will be made over each endpoint.\r
-                        Default: 1000\r
-\r
-    [ -p pipeline ]     Specify the pipline length, valid arguments are in \r
-                        the range [0,MAX_SEND_DTOS]. If a value greater than \r
-                        MAX_SEND_DTOS is requested the value will be\r
-                        adjusted down to MAX_SEND_DTOS.\r
-                        Default: MAX_SEND_DTOS\r
-\r
-    OP\r
-                        An operation consists of:\r
-\r
-                        RR|RW           Indicates the type of transfer:\r
-                                        RR  RDMA read\r
-                                        RW  RDMA write\r
-                        Defaults: none\r
-\r
-                        [ seg_size [ num_segs ] ]\r
-                                        Indicates the amount and format\r
-                                        of the data to be transferred.\r
-                                        Default:  4096  1\r
-                                                  (i.e., 1 4KB buffer)\r
-\r
-USAGE - Limit test client\r
-\r
-    Limit testing (-T L) neither requires nor connects to any server\r
-    instance.  The client runs one or more tests which attempt to\r
-    exhaust various resources to determine DAPL limits and exercise\r
-    DAPL error paths.  If no arguments are given, all tests are run.\r
-\r
-    Limit testing creates the sequence of DAT objects needed to\r
-    move data back and forth, attempting to find the limits supported\r
-    for the DAPL object requested.  For example, if the LMR creation\r
-    limit is being examined, the test will create a set of\r
-    {IA, PZ, CNO, EVD, EP} before trying to run dat_lmr_create() to\r
-    failure using that set of DAPL objects.  The 'width' parameter\r
-    can be used to control how many of these parallel DAPL object\r
-    sets are created before beating upon the requested constructor.\r
-    Use of -m limits the number of dat_*_create() calls that will\r
-    be attempted, which can be helpful if the DAPL in use supports\r
-    essentailly unlimited numbers of some objects.\r
-\r
-    The limit test arguments are:\r
-\r
-    [ -m maximum ]      Specify the maximum number of dapl_*_create()\r
-                        attempts.\r
-                        Default: run to object creation failure\r
-\r
-    [ -w width ]        Specify the number of DAPL object sets to\r
-                        create while initializing.\r
-                        Default: 1\r
-\r
-    [ limit_ia ]        Attempt to exhaust dat_ia_open()\r
-\r
-    [ limit_pz ]        Attempt to exhaust dat_pz_create()\r
-\r
-    [ limit_cno ]       Attempt to exhaust dat_cno_create()\r
-\r
-    [ limit_evd ]       Attempt to exhaust dat_evd_create()\r
-\r
-    [ limit_ep ]        Attempt to exhaust dat_ep_create()\r
-\r
-    [ limit_rsp ]       Attempt to exhaust dat_rsp_create()\r
-\r
-    [ limit_psp ]       Attempt to exhaust dat_psp_create()\r
-\r
-    [ limit_lmr ]       Attempt to exhaust dat_lmr_create(4KB)\r
-\r
-    [ limit_rpost ]     Attempt to exhaust dat_ep_post_recv(4KB)\r
-\r
-    [ limit_size_lmr ]  Probe maximum size dat_lmr_create()\r
-\r
-                        Default: run all tests\r
-\r
-\r
-EXAMPLES\r
-\r
-    dapltest -T S -d -D jni0a\r
-\r
-                        Starts a server process with debug verbosity.\r
-    \r
-    dapltest -T T -d -s linux3 -D jni0a -i 100 \\r
-    client SR 4096 2 server SR 4096 2\r
-\r
-                        Runs a transaction test, with both sides\r
-                        sending one buffer with two 4KB segments,\r
-                        one hundred times.\r
-\r
-    dapltest -T P -d -s linux3 -D JniIbdd0 -i 100 SR 4096 2\r
-\r
-                        Runs a performance test, with the client \r
-                        sending one buffer with two 4KB segments,\r
-                        one hundred times.\r
-\r
-    dapltest -T Q -s linux3 -D jni0a\r
-\r
-                        Asks the server to clean up and exit.\r
-\r
-    dapltest -T L -D jni0a -d -w 16 -m 1000\r
-\r
-                        Runs all of the limit tests, setting up\r
-                        16 complete sets of DAPL objects, and\r
-                        creating at most a thousand instances\r
-                        when trying to exhaust resources.\r
-\r
-    dapltest -T T -V -d -t 2 -w 4 -i 55555 -s linux3 -D jni0a \\r
-    client RW  4096 1    server RW  2048 4    \\r
-    client SR  1024 4    server SR  4096 2    \\r
-    client SR  1024 3 -f server SR  2048 1 -f\r
-\r
-                        Runs a more complicated transaction test,\r
-                        with two thread using four EPs each,\r
-                        sending a more complicated buffer pattern\r
-                        for a larger number of iterations,\r
-                        validating the data received.\r
-\r
-\r
-BUGS  (and  To Do List)\r
-\r
-    The server side currently runs exactly one test and exits.\r
-\r
-    There is "pause-n-pray" synchronization (sleep(n), n in {2, 10})\r
-    being used to let pre-fabricated connections work.\r
-\r
-    Use of CNOs (-Q) is not yet supported.\r
-\r
-    Further limit tests could be added.\r
-\r