Content-Type: multipart/mixed; boundary="===============1645756572891829194==" MIME-Version: 1.0 From: Stojaczyk, Dariusz Subject: [SPDK] A few thoughts about spdk_top Date: Tue, 07 Apr 2020 10:29:52 +0000 Message-ID: List-ID: To: spdk@lists.01.org --===============1645756572891829194== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I like the idea of spdk_top application, although I'm slightly concerned ab= out our implementation. Is it a right choice to develop it in C? It's alrea= dy a huge amount of code and it already has a huge amount of limitations, n= ot 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-s= ide javascript for my other projects and I find it incredibly easier to wri= te 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 scr= een? Currently spdk_top seems to require the same, detailed review as any spdk p= atch and honestly I'm a bit reluctant to review it. Moreover, I find one ma= jor feature missing there - a view with all pollers on a specific, single t= hread 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 s= pdk optimization. Yet I see it's quite a bit of effort to add it to the cur= rent spdk_top code, which brings me back to my first question. D. --===============1645756572891829194==--