[SPDK] Re: A few thoughts about spdk_top

Hi Darek,

On 4/7/20, 3:30 AM, "Stojaczyk, Dariusz" <dariusz.stojaczyk(a)intel.com> wrote:

    I like the idea of spdk_top application, although I'm slightly concerned about our implementation. Is it a right choice to develop it in C? It's already a huge amount of code and it already has a huge amount of limitations, not even mentioning possible bugs. I actually spent a lot of time developing in curses, GTK, GTKmm and even WinAPI and I don't do it anymore because it's difficult and not worth it. I switched to javascript as well as server-side javascript for my other projects and I find it incredibly easier to write user apps there. I'm not trying to push on javascript specifically, but could we consider writing spdk_top in a higher level language, where we don't care about memory allocation, json parsing, and printing data to the screen?

[Jim] I think there's room for multiple user interfaces. Personally, I like a terminal-based application like this - I typically run tmux with 4 panes, and having something like this in one pane while I'm running a target in the foreground in another works well for me.  Maybe something in Python could end up as a bit less code?  It's possible, but I look at something like spdkcli and it has quite a bit of code too.

[Jim] Regarding json parsing, I think it is nice to have another use case for our client-side JSON RPC APIs.  But you're right, there's about 300 lines of code in there specific to issuing RPCs to the app.  Potentially some of that long-term could be moved into a common library for other applications that have a need for issuing RPCs from a C application.
    
    Currently spdk_top seems to require the same, detailed review as any spdk patch and honestly I'm a bit reluctant to review it. Moreover, I find one major feature missing there - a view with all pollers on a specific, single thread and busy time % for each poller, so that I can see what my thread is most busy with. I think it would be the first view I check when doing any spdk optimization. Yet I see it's quite a bit of effort to add it to the current spdk_top code, which brings me back to my first question.

[Jim] I think now's the time to provide that feedback on what might be missing. But the basic infrastructure is all in place, and knowing Maciek I'm sure he's open to suggestions!  I'd encourage everyone to pull down the code and kick the proverbial tires.  The end of the series can be found at https://review.spdk.io/gerrit/c/spdk/spdk/+/1717/4.  I've also started reviewing individual patches and am suggesting areas where the code could be simplified a bit.  


Regards,

-Jim