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