[01:22:34] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [02:07:59] *** Quits: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) [02:13:15] *** Joins: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) [02:49:33] *** Joins: pniedzwx_ (86bfdc48@gateway/web/freenode/ip.134.191.220.72) [02:53:56] *** Joins: pniedzwx (pniedzwx@nat/intel/x-pqawdrfuuqzjyzez) [02:55:17] *** Quits: pniedzwx_ (86bfdc48@gateway/web/freenode/ip.134.191.220.72) (Quit: Page closed) [07:31:09] *** Joins: travis-ci (~travis-ci@ec2-54-235-30-28.compute-1.amazonaws.com) [07:31:10] (spdk/master) test/bdev: decrease malloc bdev size in bdev.conf.in (Seth Howell) [07:31:10] Diff URL: https://github.com/spdk/spdk/compare/ddd38a5e9d8a...7c28b8cd9471 [07:31:10] *** Parts: travis-ci (~travis-ci@ec2-54-235-30-28.compute-1.amazonaws.com) () [07:36:36] jimharris: ping [07:37:01] hey [07:37:58] Good morning. So, hate to be a pest, but can you comment on the "direction" that I and Pawel have been discussing with respect to fielding "examples" for the packaging: https://review.gerrithub.io/#/c/spdk/spdk/+/424973/ [07:39:53] i literally just posted a reply on the patch [07:40:03] Sweet! I'll look. [07:40:49] *** Quits: gila (~gila@5ED74129.cm-7-8b.dynamic.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) [07:41:38] And then related to same, accomplishing that via https://review.gerrithub.io/#/c/spdk/spdk/+/429963/ You already posted one comment to that one, but that's how I propose we facilitate packaging those example apps. [07:43:59] Specifically, you had suggested a INSTALL_APPNAME mechanism which could be used in tandem (if set) to set the name of the target, though I like to the idea of prefixing them with "spdk_example" as that is consistent to what the DPDK folks did, and when we *do* go forward with the implementation of spdk-examples pkg, then those could in theory just stay the same. [08:02:20] darsto: ping [08:02:27] pong [08:02:33] hey jim [08:02:50] hey - looking at these spdk-18.08 patches [08:03:25] the vdev sync one - it says it's a "test fix" - do you have any confirmation that it works as intended? [08:03:56] I did check it and it looks valid to me [08:04:48] in other places in dpdk where rte_mp_request_sync() is called there's also the same free() afterwards [08:05:02] I just didn't want to change the original commit message [08:05:16] you can see I added "Reviewed-by" on the bottom though [08:05:52] ok - so we need to get this patch in, and also the crypto/aesni_mb revert? [08:07:14] I said it would work once and it didn't, so I'd hold back on saying the same again [08:08:06] how about I merge them now - then can you update the SPDK patch that moves the DPDK submodule? [08:08:25] if it doesn't pass, i can manually revert those patches on spdk-18.08 with a force push [08:08:27] can you maybe update the dpdk submodule on github somehow, so I could move the dpdk submodule commit to that a temporary patch (that's still pending on gerrithub)? [08:08:48] sure - i could do that too [08:09:16] i'm in a call so won't get to it until later - i can update the submodule patch once i stage the patches to github [08:28:51] Gents, for a completely unrelated reason, I was forced to re-install my test stand operating system yesterday. [08:29:32] Afterward, I just cloned the current fio and spdk repositories, and now the fio/spdk combination will not fail - I ran it successfully overnight (eight hours), whereas I typically had failure within seconds previously, and at best 5-6 minutes. [08:29:41] The operating system is the same - literally the same DVD. [08:30:06] My only theory is that while I was trying to set up NVMe over fiber channel capability for other work, I managed to foul something. [08:30:39] The instructions I had available to do that were good but not great; since then the young lady that blazed that trail for us has updated them and they are much "tighter." [08:30:51] I followed the new version in a few minutes yesterday and had immediate success. [08:30:57] KipIngram: that's good news! [08:30:59] So that functionality is working too - it's all working. [08:31:17] YES. This has been a tough tough couple of weeks for me - it seemed like a lot of stuff didn't want to work. [08:31:47] I just pegged the last problem a few minutes ago too - my lpfc driver was limiting my queue depth, so I couldn't get to full 4k read IOPS on that fiber channel stuff. [08:31:59] But I found that and changed it a bit ago, and now the thing is cooking. [08:32:06] So I'm set to go into the weekend a happy guy. [08:33:11] I'm still not seeing the IOPS we'd like to see on the NVMe over FC (it's the regular SCSI that's cooking at the moment). But that may just be a current limitation of our product - the developers say that there's more work to do in NVMe mode for us than in SCSI, so they're not surprised IOPS are lower. [08:33:37] Our data path is all hardware, but for each operation some software stuff (address translation and so on) is required - that's what limits our 4k IOPS. [09:47:06] jimharris: https://review.gerrithub.io/#/c/spdk/dpdk/+/430115/ [09:51:11] +2 - should i merge it? [09:51:15] yeah [09:51:26] and I'm merging two more spdk-18.08 patches from Darek now [09:51:30] that you already reviewed [09:51:32] ok [09:51:33] then we can move the submodule [09:51:40] jenkins is down [09:51:43] for the lab shutdown [09:51:55] oh boy [09:52:06] I guess it's evening on Friday [09:52:11] yaeh [10:25:59] Hello All! Hey fever is fully gone nowbt I too enough Nyquil las night to knowck out a horse and I'll mseeing kind og fuzzy - letters move as I type them (kinds cool though). When this wears off, soon, I hope. I'll head on it [21:08:06] *** Quits: drv (daniel@oak.drv.nu) (Remote host closed the connection) [21:38:42] *** Joins: drv (daniel@oak.drv.nu) [21:38:42] *** ChanServ sets mode: +o drv