[00:29:29] *** Joins: drv (daniel@oak.drv.nu) [00:29:29] *** ChanServ sets mode: +o drv [01:16:09] *** Joins: tomzawadzki (~tomzawadz@192.55.54.38) [02:28:49] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [04:09:06] pwodkowx: do we want to test migration on each vhost TP machine? [04:11:32] i know I've asked about this already, but I can't remember what we've decided [04:11:41] or if we decided anything at all [04:12:51] testing on one machine should be enought, but each test take about 30s and there are two test cases. [04:13:19] we can drop one test case or split testing: TC1 on one machin, TC2 on another [04:13:29] this shoud speed this up [04:13:32] ^ that split sounds nice [04:13:59] we've got just 2 machines running vhost+vms, right? [04:14:04] fedora-06 and 08 [04:14:28] are they running mostly the same tests? [04:17:44] I think so. Is one using UIO other VFIO ? [04:24:34] yup [04:24:38] fedora-05 and 08 actually [04:25:57] fedora-05 runs for ~5min, fedora-08 runs for ~8 [04:28:01] fedora-05 runs only UT and lvol-based vhost tests [04:29:23] so actually, maybe we should put all migration tests into fedora-05? [06:44:07] klateck - in lvol test #700 - can we reduce size of each lvol from 10% of lvolstore size to 2%? [06:44:27] i ran some tests yesterday and this reduced per-patch time by 24 seconds [06:45:24] we are adding live migration tests on fedora-08 - this adds 40 seconds to test pool time so started looking at other tests already running on that system [06:45:49] we may move the lvol tests to another system, but seemed like this was still a sensible change either way [06:47:12] I was going to suggest that - that we run vhost + lvols on fedora-08 and vhost+migration on fedora-05 [06:47:46] ok - so i guess we just need a new SPDK_TEST_VHOST_MIGRATION flag? [06:47:46] Or maybe the other way around - vhost + live migration on physical fedora-08 and lvol tests on fedora-05 VM [06:47:55] yup [06:48:03] either way we'll need that flag I think [06:48:13] And if you're okay with lowering the size of IO in lvol tests then we can do that as well [06:50:05] Does this 24 second improvement show on both fedora-08 and fedora-05? It's suprising to see such time gain, especially that bdevs used in that test are rather small (64MB I think) [06:53:09] i think we'll only see that gain on fedora-08 - since it uses a physical NVMe device [06:54:04] Oh, right. TC #700 uses NVMe, not 64MB Malloc [07:23:28] *** Quits: nKumar (uid239884@gateway/web/irccloud.com/x-ksohefcqbvwdpchq) () [07:23:41] *** Joins: nKumar (sid239884@gateway/web/irccloud.com/x-nfnqldjvawstbntm) [07:58:53] *** Joins: toka (86bfdc49@gateway/web/freenode/ip.134.191.220.73) [08:33:16] *** Quits: tomzawadzki (~tomzawadz@192.55.54.38) (Ping timeout: 265 seconds) [10:05:18] jimharris: I'm not sure how the spdk.unittest.mk modifications are supposed to work; how does it find the right source files for OTHER_FILES after you remove the %.o rule? [10:05:46] (maybe we could just get rid of OTHER_FILES in the few places we use it and #include those directly) [10:06:49] hmmm - yeah, I guess in my build environment it didn't catch that for some reason [10:06:56] i'll take a look [10:07:51] maybe you had some .o files left over from previous builds [10:30:54] this patch series is going to remove almost 700 lines of duplicated Makefile rules [10:32:56] nice [11:06:54] *** Quits: toka (86bfdc49@gateway/web/freenode/ip.134.191.220.73) (Quit: Page closed) [11:34:41] drv: can you take a look at https://review.gerrithub.io/#/c/398326/ [12:30:04] seems OK at first glance, but I don't know enough vhost protocol details to say if it's right for sure [15:17:03] drv, jimharris : FYI I posted the latest vbdev passthru with testcode. There's something strange going on w/the test, the ndb test will sometimes fail after multiple runs and it does seem to have something to do with the vbdev being in there. Then again, without the vbdev there's still and ASAN issue with the block tests so I'm thinking about trying to figure that out first and then coming back to this. But if you get a chance to look through the main entry [15:17:03] points in the PT code that's be cool too. Will keep ya posted [15:23:58] PS: the other failures in CI are different than what I just mentioned. Couple of them are obvious, a scan-build thing and another match thing I need to tokenize, etc. [15:52:53] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [15:56:26] Our product team started to merge the upstream and it will be great if it is merged. [15:56:54] I know you have a long queue of review and I have not contributed much as reviewers... hence this is not urgent and I can wait of course. thank you. [16:07:10] Shuhei: do you mean you have some particular patches you'd like to get reviewed? [16:07:30] if you highlight some that are ready to go and just need maintainer review, we will take a look [16:07:53] peluse: can you link to the nbd failure? the ones I see in the latest run are all due to the match failing with different number of free clusters [16:09:41] drv, its when I run it locally. I have to run it 2-3x in a row (just blockdev.sh) and for a while was moving an "exit 0" down after each run starting with just running the PT tests. Was able to do several in a row until I added in the nbd tests. I'll post some more info on it later and will also fix the known stuff on CI so maybe it will show up there too. thanks! [16:09:46] oh, ok [16:31:54] Please queue it in your list. [17:32:32] drv: how should we point to the prerequisites from doc/README.md? i mentioned using a @ref but now I'm not sure that's what we want: https://review.gerrithub.io/#/c/399786/1/doc/README.md [17:49:37] @ref won't work in README.md as it's not a Doxygen input file [17:49:54] we could just use a regular Markdown-style link []() [18:18:42] Hi Daniel, Sorry I found the defect in the patch I said. Please wait for my update and sorry for inconvenience.