[00:21:35] Hi ksingh, what kind of information do you need in particular? [00:41:54] Shuhei: I replied on https://review.gerrithub.io/c/396576/ [00:42:13] why do you want to split this loop? [01:52:59] drv, jimharris: I tested https://review.gerrithub.io/#/c/386546/ on current QEMU master (f24ee107a07f "Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180202-pull-request' into staging") and look like it is working. Can we switch to QEMU and merge this patch? [02:37:28] Is there an iCal invite or Google Calendar for the SPDK community call? [02:38:59] (That way the meetings appear in a calendar automatically without needing to manually add entries when meetings are announced on the mailing list) [02:40:29] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [03:50:08] don't think so, but this is good idea [06:31:28] pwodkowx: I'll look into the qemu update today [07:56:32] do we need very latest qemu master, or can we pick a release tag instead? [07:57:52] drv: pwodkowx says it has to be the specific commit he pointed out [07:58:01] hmm, ok [07:58:02] release tag is too old [07:58:51] I plan to create another branch on our spdk/qemu fork to track what we are using on our test machines - I'll create it from the commit above unless I hear otherwise [07:59:11] then we can get that version built and installed (in a new location) on all the test machines, and then switch the test scripts to use that new location [07:59:37] and once all that is working, we can cherry pick those patches for v18.01.1 [08:37:42] *** Joins: tomzawadzki (~tomzawadz@192.55.54.44) [08:51:06] drv was reviewing patches at 6:57am this morning? [08:51:20] I had an early meeting [08:51:55] any patch reviews I made before 8:30 AM are probably suspect :) [08:52:01] lol [08:57:56] regarding a meeting invite for the SPDK community call, it would be good to send out a mailing list post once a week as a reminder (and attach the calendar invite) [08:58:12] assuming mailman doesn't filter those [09:15:35] *** Quits: tomzawadzki (~tomzawadz@192.55.54.44) (Ping timeout: 260 seconds) [09:44:20] hmm, just noticed that the subsystem pause check in spdk_nvmf_request_exec() has a three-level-deep pointer chase [09:44:28] 'if (qpair->group->sgroups[qpair->ctrlr->subsys->id].state != SPDK_NVMF_SUBSYSTEM_ACTIVE)' [09:44:49] I wonder if we can stash a copy of that subsystem group pointer somewhere more convenient so we don't need to do that on every request... [09:50:13] sgroups can get realloc()'d, which makes things more complicated (can't store a direct pointer to sgroup since it may move) [10:44:35] *** Joins: AlanA (9457170b@gateway/web/freenode/ip.148.87.23.11) [11:33:23] sethhowe, not a big priority but when you get a chance can you see why this blog post doesn't seem like its getting picked up by CI? https://review.gerrithub.io/#/c/395663/ [11:55:49] *** Quits: ksingh (c6ba0407@gateway/web/freenode/ip.198.186.4.7) (Ping timeout: 260 seconds) [16:06:04] peluse: pushed your "match" patch - Daniel and I both had a comment in there on some additional changes that should be made but you can add those in a separate patch [16:06:28] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [16:42:19] Hi Jim, Daniel, how do you think using exponential moving average (https://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average) to bdevperf? [16:44:40] for runtime IOPS display? that sounds like a good idea to me [16:44:57] Hi Daniel, yes. [16:45:29] I started to create a patch. If I push it to Gerrit, please review it. [16:46:06] Gang is proposing an idea related with it and I will let him know it too. Thank you. [16:46:11] we could also do a simpler weighted moving average if the exponential function is too expensive to compute at runtime, but either way is good [16:47:38] I will take simpler one too. Thank you. [22:01:22] *** Joins: ziyeyang_ (~ziyeyang@192.55.54.42) [23:04:19] *** Quits: ziyeyang_ (~ziyeyang@192.55.54.42) (Ping timeout: 240 seconds) [23:17:13] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.76) [23:20:56] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.76) (Remote host closed the connection)