Rename dapltest.txt --> dapltest_how_2.txt for easy
authorstansmith <stansmith@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Fri, 30 Mar 2007 02:57:57 +0000 (02:57 +0000)
committerstansmith <stansmith@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Fri, 30 Mar 2007 02:57:57 +0000 (02:57 +0000)
visual recognition. Updated content to reference current
ibnic0 device instead of linux dev.

git-svn-id: svn://openib.tc.cornell.edu/gen1/trunk@620 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86

ulp/dapl/test/udapl/dapltest/DaplTest_how_2.txt [new file with mode: 0644]

diff --git a/ulp/dapl/test/udapl/dapltest/DaplTest_how_2.txt b/ulp/dapl/test/udapl/dapltest/DaplTest_how_2.txt
new file mode 100644 (file)
index 0000000..8085e39
--- /dev/null
@@ -0,0 +1,292 @@
+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
+\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 hostname of the dapltest server.\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:  \r
+    \r
+    Due to the flow control algorithm used by the transaction test, there \r
+    must be at least one SR OP for both the client and the server.  \r
+\r
+    Requesting data validation (-V) causes the test to automatically append \r
+    three OPs to those specified. These additional operations provide \r
+    synchronization points during each iteration, at which all user-specified \r
+    transaction buffers are checked. These three appended operations satisfy \r
+    the "one SR in each direction" requirement.\r
+\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 hostname of the dapltest server.\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
+                        Default: 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 ibnic0\r
+\r
+                        Starts a server process with debug verbosity.\r
+    \r
+    dapltest -T T -d -s winIB -D ibnic0 -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; dapltest server is on host winIB.\r
+\r
+    dapltest -T P -d -s winIB -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 winIB -D ibnic0\r
+\r
+                        Asks the dapltest server at host 'winIB' to clean up and exit.\r
+\r
+    dapltest -T L -D ibnic0 -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 winIB -D ibnic0 \\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
+    Use of CNOs (-Q) is not yet supported.\r
+\r
+    Further limit tests could be added.\r