[SPDK] Re: spdk_top vs application mystery

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