From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0711216329725607678==" MIME-Version: 1.0 From: Stojaczyk, Dariusz Subject: [SPDK] Re: A few thoughts about spdk_top Date: Wed, 08 Apr 2020 08:28:10 +0000 Message-ID: <84447b13e6ac44038eb9af9778cae433@intel.com> In-Reply-To: 88368B06-746A-44CD-8CFC-1097A01518D3@intel.com List-ID: To: spdk@lists.01.org --===============0711216329725607678== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Harris, James R > Sent: Wednesday, April 8, 2020 12:14 AM > To: Storage Performance Development Kit ; Szwed, Mac= iej > > Subject: [SPDK] Re: A few thoughts about spdk_top > = > 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 concer= ned 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 cu= rses, > GTK, GTKmm and even WinAPI and I don't do it anymore because it's difficu= lt > and not worth it. I switched to javascript as well as server-side javascr= ipt 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 li= ke 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 s= pdkcli and > it has quite a bit of code too. Agreed. I prefer CLI apps where possible, although what's the good way to d= evelop them? I know spdkcli needs to fit in the targetcli-like framework in Python, so t= here's a fair amount of framework specific code. Maybe for spdk_top we don'= t necessarily need a framework, just a library? This could use a research t= o see what's available. I heard DPDK develops a similar application in Go, although I can't find th= e code anywhere. There's a presentation on the internet [1] with some scree= nshots and I have to say it does look impressive. They even draw graphs in = CLI, however I slightly question usability of that in particular. I just don't see our C implementation ever getting as functional as the DPD= K one. > = > [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 n= eed > for issuing RPCs from a C application. That's a good point. > = > 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 thr= ead and > busy time % for each poller, so that I can see what my thread is most bus= y with. > I think it would be the first view I check when doing any spdk optimizati= on. Yet I > see it's quite a bit of effort to add it to the current spdk_top code, wh= ich brings > me back to my first question. > = > [Jim] I think now's the time to provide that feedback on what might be mi= ssing. > 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 ki= ck > 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 re= viewing > individual patches and am suggesting areas where the code could be simpli= fied > a bit. > = > = > Regards, > = > -Jim > = > = > _______________________________________________ > SPDK mailing list -- spdk(a)lists.01.org > To unsubscribe send an email to spdk-leave(a)lists.01.org [1] https://www.dpdk.org/wp-content/uploads/sites/35/2019/10/MeasuringSoftw= arePerformance.pdf (slide 19+) D. --===============0711216329725607678==--