diff-perftest-08 [was: Re: [openib-general] Re: Re: diff-perftest-07 replace pp_get_local_lid()]

[Michael S. Tsirkin]

Quoting r. Bernhard Fischer <bernhard at aon.at>:
> Subject: diff-perftest-08 [was: Re: [openib-general] Re: Re: diff-perftest-07 replace pp_get_local_lid()]
> 
> Looking at the code, 1 is the default and not 4096 as advertised (see
> attached patch to reflect default of 1 in usage).
> 
> o Change usage() to match the actual default of size.
> o sparse warning amout non-ANSI function decl of get_cpu_mhz(),
>   whitespace in printf while at it.
> o Check arguments -s and -t
> o Trim some whitespace
> Signed-off-by: Bernhard Fischer <rep.nop at aon.at>

I applied these.

> o Add printing Size, TX-depth and Iters to print_report().
>   Without a short description of the workload, it is bit hard to
>   interpret the results if one cannot see the command-line used to run
>   the tests.

Why not print out the command line?

Further, I'd like to avoid passing the context to print_report.
But I wouldnt object to -V (--verbose) flag:
when set, print all the parameters out, and do it in main, right after they
are parsed; further it might be a good idea to print the connection data only
when this flag is set.

> o Remove odd 'write(sockfd,"foo"...' (What was that good for?)

Its actually useful for debug (when there's a bug
and server/client get out of sync, instead of blocking forever,
one side gets woken with a wrong message so it can detect this and exit).

Anyway, eventually we have to replace all this code:

           Arbitrarily reuse exch_dest for this purpose. */
        if (servername) {
                rem_dest = pp_client_exch_dest(sockfd, &my_dest);
        } else {
                rem_dest = pp_server_exch_dest(sockfd, &my_dest);
        }

        write(sockfd, "done", sizeof "done");

with each side sending a message saying the qp is ready to receive,
and waiting for the other side to do so.


> I can specify -s 940 as the maximum, using 941 gives me "cannot create
> QP" in rdma_lat.c. Is this expected?

> What are the contraints and limits
> for size here?

Right. Thats because the test currently uses inline data unconditionally.
And *that* is because the maximum legal inline data size cant be queried from
the device yet.
Need to fix that in uverbs: there does not seem to exist a way now to query hca.

> 
> Quick unrelated question:
> Is there any limit on the number of cqe's i can pass to mthca_create_cq?
> I initially tried 40960 or 4096 but that did not work. I'm now using 64
> but would like to use more than those in the future..
> 
> 

I would expect 40960 or 4096 to work. Roland? What am I missing?

-- 
MST - Michael S. Tsirkin