From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0258001017689598020==" MIME-Version: 1.0 From: Harris, James R Subject: [SPDK] Re: A few thoughts about spdk_top Date: Tue, 07 Apr 2020 22:13:50 +0000 Message-ID: <88368B06-746A-44CD-8CFC-1097A01518D3@intel.com> List-ID: To: spdk@lists.01.org --===============0258001017689598020== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Darek, =EF=BB=BFOn 4/7/20, 3:30 AM, "Stojaczyk, Dariusz" wrote: I like the idea of spdk_top application, although I'm slightly concerne= d about our implementation. Is it a right choice to develop it in C? It's a= lready a huge amount of code and it already has a huge amount of limitation= s, not even mentioning possible bugs. I actually spent a lot of time develo= ping in curses, GTK, GTKmm and even WinAPI and I don't do it anymore becaus= e it's difficult and not worth it. I switched to javascript as well as serv= er-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 cou= ld 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 f= or our client-side JSON RPC APIs. But you're right, there's about 300 line= s of code in there specific to issuing RPCs to the app. Potentially some o= f that long-term could be moved into a common library for other application= s that have a need for issuing RPCs from a C application. = Currently spdk_top seems to require the same, detailed review as any sp= dk patch and honestly I'm a bit reluctant to review it. Moreover, I find on= e major feature missing there - a view with all pollers on a specific, sing= le 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 a= ny 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 miss= ing. But the basic infrastructure is all in place, and knowing Maciek I'm s= ure 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 http= s://review.spdk.io/gerrit/c/spdk/spdk/+/1717/4. I've also started reviewin= g individual patches and am suggesting areas where the code could be simpli= fied a bit. = Regards, -Jim = --===============0258001017689598020==--