9:04 p.m.
Hi,
See main() in bdevperf.c. It sets opts.rpc_addr to NULL after the opts structure is
initialized. If the user does not specify -r, then this field remains NULL when
spdk_app_start() is called. That tells the event framework to disable the JSON-RPC
listener. spdk_top will not work in that case since it requires JSON-RPCs to collect its
data.
It is a very common use case to use bdevperf in conjunction with an SPDK target
application such as nvmf_tgt or spdk_tgt. The SPDK target application would typically
already be using the default /var/tmp/spdk.sock for its JSON-RPC listening socket. This is
why we require bdevperf users to specify a JSON-RPC pathname, since in many cases the
default one will already be in use.
Regards,
-Jim
On 2/8/21, 12:04 PM, "nufosmatic(a)nufosmatic.com"
<nufosmatic(a)nufosmatic.com> wrote:
v20.10
I have an application I built derived from "hello_world" for bdev. It's
been working with spdk_top right along. Very nice.
I modified a copy of bdevperf and spdk_top did nothing with it. I finally tried adding
the "-r <path>" option that comes out of the framework, and it magically
danced to life!
The question is why I don't have to use the "-r <path>" with the
modified "hello_world" for bdev and why I do have to specify "-r
<path>" (specifically -r /var/tmp/spdk.sock) for bdevperf. I don't see any
differences in the spdk application startup. Or a better question is why the RPC server is
inhibited in the one bdevperf case unless and until the option is given to the
application. Can you give me some place to look?
I just sent back to "hello_world" for bdev, added a spin-delay before the
spdk_app_stop(), and it also responded to spdk_top. (Kinda boring output, but it
connected...) No "-r <path>" necessary...
Mystery...
_______________________________________________
SPDK mailing list -- spdk(a)lists.01.org
To unsubscribe send an email to spdk-leave(a)lists.01.org