--- /dev/null
+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
projects / ~shefty / rdma-win.git / commitdiff