[08:12:02] peluse: there is a "Drafts" option for gerrit - you have to push to a different remote branch for patches to get marked as Drafts [08:12:35] and then when the patch is ready for review, the author and authorized admins have a "Publish" button to mark it ready [09:34:03] bwalker, drv: can you review the latency patch again? I fixed the off-by-one bug in the number of latency bucket ranges [09:34:06] http://spdk.intel.com/gerrit/#/c/7853/7 [09:34:14] also the dpdk submodule patch is ready to go in [09:44:23] Where can I find that fio config file you had on our site for the blobstores? [09:44:39] ben, Where can I find that fio config file you had on our site for the blobstores? [09:44:46] See gerrit review 7515 [09:45:02] thanks [09:48:26] peluse: I made some comments on your UT coverage patch [09:49:16] drv, thanks will take a look shortly [10:16:02] just a heads up, status page on spdk will not update for the duration of this build. I accidentally killed that thread while exiting a tmux session. I'll put it back online after this build finishes. [10:19:36] Status page is back to updating. [11:30:37] *** Joins: jstern_ (~jstern@134.134.139.74) [13:01:55] I'm losing my mind... up until today I could git rebase or git pull without any problems having dpdk as an untracked dir in my repo. Now it won't let me do either operation, anyone know whats happenin? [13:01:59] error: Updating the following directories would lose untracked files in it: [13:01:59] dpdk [13:02:19] .. and then "Aborting" and I get nada [13:04:45] jimharris made your life difficult ;) [13:05:01] we have a dpdk submodule now, so you should be able to remove/rename whatever dpdk you have right now and let the submodule replace it [13:05:14] ahhh.. thought I was losing my mind [13:05:21] but that may stil be true [13:06:31] drv, much better.. gracias [13:09:05] jimharris, looks like the readme in the repo got updated for the submodule info but the build instructions for dpdk got removed [13:10:06] it should get built automatically if you do not specify --with-dpdk in your configure command [13:10:24] by the SPDK make invocation, that is [13:10:54] OK, the new readme just says that it will fetch automatically [13:13:42] well, something doesn't seem to be right. If I create a new repo and simply run the configure command in the readme and try to make dpdk isn't built [13:13:58] is the dpdk submodule actually fetched? [13:14:10] doesn't look lke it [13:14:24] nope dir is empty [13:14:32] I don't think it actually does the submodule init automatically [13:14:36] jimharris: ^ [13:14:55] yeah, the readme says "Older versions of git may require:" and then lists the 2 submodule commands [13:15:32] yeah, I don't think that part is right - you will always need to do the git submodule init yourself (as far as I know) [13:15:59] which will give me a version of dpdk, latest?? Or how do we the the one we want to be included at any given point in time [13:16:01] ? [13:16:33] the submodule will point at a DPDK version that is known to work with the version of SPDK you have checked out [13:16:41] cool [13:17:09] right now it's on DPDK v17.02 plus a few of our own patches [13:17:37] still not working for me... one min [13:18:16] I haven't actually tried a clean checkout myself - let me give it a whirl too [13:20:01] seems to work for me (git clone https://github.com/spdk/spdk.git; cd spdk; git submodule init; git submodule update; ./configure; make) [13:21:30] I had to go make dpdk separately. Did you run ./configure --with-dpdk=./dpdk/x86_64-native-linuxapp-gcc before make or just what you typed exactly? [13:21:56] no, if you specify --with-dpdk it will assume that you have built it yourself [13:22:05] if you don't specify --with-dpdk then it will use the submodule automatically [13:22:33] OK, then the readme needs to be udpated [13:23:00] hmm, yeah, the way it's written now is wrong [13:23:21] yeah, if I just to ./configure then make it works like a champ [13:23:52] drv, you wanna update it or want me to? [13:24:49] peluse: go for it - it looks like the --with-dpdk parameter is already explained in the Advanced Build Options section below, so you can just nuke it from that first example [13:25:06] and also update the wording about automatic fetching - not sure where that idea came from [13:25:11] maybe jimharris has some explanation :) [13:26:02] coolio [13:31:37] when did git clone --recursive support get added to git? [13:33:01] looks like v1.9 [13:33:10] but --recursive is not on by default [13:33:56] yeah - we need to add --recursive to the readme [13:34:10] jimharris, OK I was about to push. [13:34:11] older revs need to do the submodule commands [13:34:40] I think most people will probably git clone first and ask questions later [13:34:42] jimharris, add that to the clone? and older revs of what, git? What will they do if you specify --recursive, do we know? [13:34:49] so it's probably easiest to just keep the explicit submodule init command [13:34:59] agreed [13:35:14] but then some smart ass will comment that its not the best way to do it :) [13:35:19] you can simplify it down to git submodule update --init if you want [13:35:38] cool [13:43:51] done [13:52:16] ok - sorry, was in a 1x1 [13:52:48] so some of this I pulled from the vpp readme's but now that I look vpp's definition of "old" is much different than mine [13:53:00] from what I can tell, --recursive was only added in 2014 timeframe [13:53:10] so git submodule update --init should be a required step [13:56:13] hmm, something funky is going on with the nvmf_tgt+fio test - I wonder if this is tickling the same bug as Ziye found with our fio_plugin [14:14:41] i know the script says "Hangup", but fio says "terminating on signal 15" which is SIGTERM [14:15:39] I think it is just hanging and hitting the test pool timeout, which is the same behavior as we saw with fio_plugin with multiple threads [14:15:44] and this is using 3 fio threads [14:17:05] status page down? [14:18:06] it is for me [14:18:16] we're about to merge a 4 patch series, so he's working on it [14:18:25] I think changing the configuration files [14:26:35] *** Quits: jstern_ (~jstern@134.134.139.74) (Ping timeout: 240 seconds) [15:53:54] drv, U there? [15:54:22] peluse: yup [15:55:38] drv, wait... never mind :) [15:58:37] no, mind again. question about your suggestion to use $UT_COVERAGE in autotest.sh. Well a few questions... [15:58:43] sure [15:59:13] first, specific to your comment since autotests calls out to unittest.sh we don't need to set the var there, it will be done in unittets.sh right? [16:00:20] we'd just need to update the end of autotests to collect the cov info from the new location where UT coverage info is going to be fond (and new filenames)? [16:00:23] this is some tricky not-really-documented stuff about how autotest.sh figures out where to put its output [16:00:40] autotest.sh has a variable called $out that points to the location that gets copied to the pool /builds/review/... dir [16:00:56] but unittest.sh doesn't/shouldn't know about that, since it needs to be runnable by a dev on their box [16:01:04] yeah, I just removed that from unittests.sh ($out) as its not needed at all there [16:01:24] so autotest.sh should just `export UT_COVERAGE=$out/ut_coverage` [16:01:28] before running unittest.sh [16:01:36] Ohhh.... [16:01:44] so then the output will be copied onto the build server for each machine [16:01:59] we can do some more magic later to consolidate all of the unit test coverage outputs like we do for coverage/ today [16:02:09] but that really shouldn't be necessary since hopefully all machines should get the same unit test coverage [16:02:25] OK, what about the magic crap at the end where it's collecting info or in the build pool script or wherever that was. unittests.sh is now using different filenames so don't we need to use those here as well? [16:02:58] you mean the whole "local unit test coverage" block at the end of unittest.sh? [16:03:04] or something else? [16:03:26] also definitely don't want to automatically run git clean, don't listen to bwalker [16:03:31] at the end of autotests.sh # generate coverage data and combine with baseline [16:03:32] we should only clean files that we made [16:03:43] oh, that is still needed for the whole system-test coverage [16:03:47] hah, git clean can take a wildcard though [16:04:15] OK, there are too many UT coverage output filenmaes for me to keep track of :) [16:04:23] yeah :) the normal 'coverage' directory is for all tests [16:04:29] and that stuff should all be in autotest.sh [16:04:37] your new unittest.sh coverage should be totally separate from that [16:04:52] today, coverage will still include the unit test coverage too, but we'll fix that later [16:04:52] I'll add the export UT_COVERAGE and make the couple of edits in unittests.sh and see what happens. [16:05:01] cool, let me know if you hit any snags [16:05:40] my question I guess is that since autotest.sh is relying on unittets.sh to get UT coerage info and I just changed the outputfilenames in unittests.sh surely (yes I just called you that) some other script somewhere needs to know what the new names are? [16:07:27] OK, cool enough [16:07:41] I can't test autotests.sh changes right now so will just fire and forget I guess... [16:08:02] yeah, I know it looks like that's what I've been doing so far anyways :) [16:20:24] so dpdk doesn't .gitignore any build directories, libraries, etc. [16:20:51] yeah, I noticed that right away and went back to building it out of tree [16:21:05] i'm tempted to add "build" to .gitignore on our branch [16:21:16] makes it easier to use that as-is [16:21:27] rather than our core developers deciding not to use it :) [16:22:07] any objections? I don't want to add a bunch of patches to our dpdk repo, but this seems like a reasonable one that will basically never change [16:22:17] yeah I already almost submitted it myself [16:22:25] so fine by me [16:23:31] drv: blobfs test seems to be failing due to a failed spdk_nvme_ns_cmd_read|writev in the bdev nvme driver [16:23:58] so pushing a patch to print out the return value when it fails [16:24:18] not a lot of options for failed return values there but want to know which it is before I start debugging further [16:25:00] hm, sounds sketchy [16:25:06] hopefully it's not our drive actually failing? [16:25:27] can't be that - the submission fails [16:25:31] oh [16:25:40] I suppose it could be due to the request allocation changes [16:26:22] we set the default to 512 entries per I/O queue [16:26:30] and this is failing on the overwrite test [16:26:37] if the blob store is assuming it can queue more than that in software, we are in trouble [16:26:43] so it's not like there should be a ton of I/O outstanding - should mostly be large reads and writes from compaction [16:27:37] just fyi - the rocksdb output files are there in the output too - if you see the overwrite test fails, there is an overwrite_db_bench.txt file that will show more details on how db_bench failed [16:28:22] whats the easiest way for me to go back and look at older test runs to confirm all of the recent rocksdb test failures in the pool have been a submission failure? [16:30:02] hmm, you have a login for spdk.intel.com if you want to look directly at the logs in /home/public/spdk/builds/ [16:35:11] https://ci.spdk.io/status/ [16:35:17] sethhowe has been busy [16:36:20] the Gerrit links won't work yet [16:36:44] yeah - not live yet [16:39:26] drv: I found 2 other release build failures due to rocksdb [16:39:33] both are due to this same IO submission failure [16:39:39] 2 were on reads [16:40:19] 1 was on a write, which didn't fail db_bench immediately - it was caught in the next test run when reading that block and noticing checksum error [16:41:35] did you discover what the error code was? [18:17:46] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.73) [21:21:23] *** Joins: anakli (800cf50a@gateway/web/freenode/ip.128.12.245.10) [21:23:46] *** Quits: anakli (800cf50a@gateway/web/freenode/ip.128.12.245.10) (Client Quit) [21:24:49] *** Quits: ziyeyang_ (~ziyeyang@134.134.139.73) (Quit: Leaving)