[00:41:16] Anyone is online? [00:57:35] *** Quits: ziyeyang_ (~ziyeyang@192.102.204.38) (Remote host closed the connection) [00:57:35] *** Quits: ziyeyang__ (~ziyeyang@192.55.46.46) (Remote host closed the connection) [01:21:05] klateck is restarting the TP at the moment [01:21:29] ziyeyang__ [01:43:40] Restarted CH TP. I see the queue populated with all the missed commits, but I don't see any "In progress" build [01:43:45] at least not yet [01:58:28] *** Joins: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) [02:02:10] *** Quits: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) (Client Quit) [02:16:32] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [02:25:02] I've been using NBD (mostly because its so simple to test some stuff) but I noticed, that unlike most things in SPDK, it does not scale. I.e adding more NBD devices (and even cores) does not make NBD go faster in terms of IOPS. Does anyone know where the bottleneck is? [02:36:04] gila: the nbd module was never meant to be efficient. It's mostly used for testing or maintenance [02:37:28] I understand and appreciate that -- still though, do you happen to know why it does not scale? [02:37:31] I looked through the code now and I see that all NBD devices are polled on a single thread - the same that's used for rpc [02:37:43] Oh ok [02:38:32] So that then seems to be there problem [02:44:09] the nbd module actually has a nice API, so if you're really interested into squeezing some more iops from it, then you could implement a simple spdk app that creates nbd devices on different threads [02:44:51] but then the nbd socket reads/writes will become a bottleneck [02:46:58] Right -- the sys calls will be the bottleneck for sure. it was just a little surprising to me to see that when adding cores it did not get better with multiple NBD devices [03:27:47] *** Joins: tomzawadzki (uid327004@gateway/web/irccloud.com/x-vhodlrcicayydhdd) [04:02:36] *** Joins: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) [04:49:33] peluse can you take a look here and tell us if it's possible for test/app/match to use arguments? https://review.gerrithub.io/#/c/spdk/spdk/+/432958/ [04:51:00] Chen wants to test get_nvme_controllers to see if controller name and bdf addr match what is expected [04:51:11] Can we pass bdf addr as an argument to match app? [05:09:27] we basically want to use some variables in the match template [05:10:07] no, I think we don't want to have template for every invokation of match app [05:11:59] but we do want to have the tests [05:12:14] yes, we want [05:12:25] match seems to be a good choice for testing complex output [05:12:33] - like RPCs [05:12:43] but imagine that everytime sed or grep is used you need to create separate file with match pattern [05:15:01] I don't negate using match app or any other tool. I just don't want to: [05:15:42] 1. analyze pearl script everytime I see template for this app (try match --help, It's not helpfull) [05:16:02] 2. have zylion files in repo just to contain JSON remplate [05:18:26] BTW: what is the "beautiful" the match app provides that standard diff can't produce? [05:18:46] * "beautiful" output the ... [05:20:56] for this particular test there's not much difference between using the two [05:21:56] in spdkcli tests there are those $() wildcards that match any string, any number, or so [05:23:11] I can't really imagine maintaining a zylion separate grep calls [05:23:59] whereas maintaining a zillion match files seems fine [05:27:56] If we allow using this match app everywhere about of *.match files will increase exponentially like a virus. [05:29:14] about spdkcli tests: why we just didn't used JSON schema? [05:29:35] * ..everywhere amout of... [05:29:50] the question is how can we possibly avoid that [05:30:25] combine multiple *.match rules into a single file? [05:30:41] it would be the same issue with diff [05:31:28] (creating temporary files through bash is a no no) [05:33:08] I think we need a trello card for next community meeting. We need to avoid this mine field ASAP. [05:33:26] ^ [05:50:47] pwodkowx I don't think you need to analyze match perl script in case of fail. IMO you should just focus on the result it provides. Especially that in case of fail it prints the diff between the files. [05:52:10] BTW about spdkcli tests - do we have JSON schema support now? We didn't when these scripts were first created. But if we do now then it'd be good to use them [05:53:44] Oh, and CH TP is picking up builds now, I forgot to write that before. The queue is long though... [06:08:40] *** Quits: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) (Ping timeout: 250 seconds) [06:47:54] i don't think spdkcli tests check json output [06:48:12] it's that cli-ish output that's supposed to be human friendly [06:48:34] the same you see in spdkcli [07:26:11] lots of fun match discussion! Yea, probably best to discuss in the comm meeting... [07:27:05] peluse: klateck had to leave early today and won't be there on the call [07:27:14] he just asked me to tell you [07:27:27] ahh, OK thanks [07:27:40] I'll just cancel then, I saw his email update.... thanks [08:22:36] *** Joins: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) [08:28:32] can somone launch on TP an Jenkins this patch? https://review.gerrithub.io/#/c/spdk/spdk/+/438318/ [09:21:47] will do in a minute [09:37:30] pwodkowx_, are you saying that Jenkins didn't pick it up? [09:37:35] how long as it been? [09:37:57] darsto, before you do anything I'd like to understand if there's an issue or not and investigate before doing anything else [09:38:44] peluse: it's just a patch from a non-whitelisted person [09:39:02] everything's working as expected [09:39:13] Oh, OK. Thanks. Let me check the last script run real quick and make sure it was correctly identified that way.... one sec [09:40:19] yup, yup. The script correctly skipped running it because its not on the whitelist. Looks like it has an approval button entry as well, awesome :) [10:07:47] *** Quits: pwodkowx_ (~pwodkowx@84-10-19-38.static.chello.pl) (Ping timeout: 240 seconds) [10:27:23] *** Quits: tomzawadzki (uid327004@gateway/web/irccloud.com/x-vhodlrcicayydhdd) (Quit: Connection closed for inactivity) [11:26:07] *** Joins: darsto_ (~darsto@89-78-174-111.dynamic.chello.pl) [11:27:24] *** Quits: darsto (~darsto@89-78-174-111.dynamic.chello.pl) (Ping timeout: 272 seconds) [11:27:24] *** darsto_ is now known as darsto [15:14:00] anyone else running into rbd failures in the CH TP? I've got 2 in a row on an unrelated patch... https://ci.spdk.io/spdk/builds/review/2c2765ff1f13f7d3b5d6cef08f014cde2856852c.1546027431/fedora-02/build.log [19:19:42] *** Joins: ziyeyang__ (~ziyeyang@192.102.204.38) [19:19:42] *** ChanServ sets mode: +o ziyeyang__ [20:44:01] *** Quits: ziyeyang__ (~ziyeyang@192.102.204.38) (Ping timeout: 268 seconds)