[00:09:16] *** Joins: travis-ci (~travis-ci@ec2-54-205-253-175.compute-1.amazonaws.com) [00:09:17] (spdk/master) configure: Correctly hyphenate ISA-L (Ben Walker) [00:09:17] Diff URL: https://github.com/spdk/spdk/compare/fdb675cad554...7b74567eb13b [00:09:17] *** Parts: travis-ci (~travis-ci@ec2-54-205-253-175.compute-1.amazonaws.com) () [02:27:29] *** Joins: pawelkax (pawelkax@nat/intel/x-kztvyqyzihntwxca) [04:13:43] *** Joins: davidsha (davidsha@nat/intel/x-msqpracmnrtecnze) [05:16:32] bwalker: seems like you reverted the H3C SPDK whitepaper patch on github, but not on gerrithub [05:16:57] and the automatic gerrithub->github sync doesn't work now [05:18:05] I rebased the 19.01 article on top of that revert and pushed it to github [05:18:52] can I push -f the same to gerrithub, so it can be in sync? [05:19:02] sethhowe, won't that break anything? [06:12:59] *** Joins: gila (~gila@85.159.237.67) [07:03:19] darsto: you can try that. The only thing it would break is the sync which is already broken. If that doesn't work, I can e-mail GerritHub support to have them fix it on their end. [07:14:39] gerrithub says nope [07:14:40] remote: You need 'Push' rights with 'Force' flag set to do a non-fastforward push. [07:28:36] darsto: OK. We can see if bwalker has those permissions when he gets into the office today (I know I don't). Then I'll e-mail GerritHub. They usually fix things like this within 48 hours. [07:31:34] I don't think we need to email gerrithub. If pushing to gerrithub by force won't work, we can always push the revert to gerrithub for review, merge it there and then push -f to github [07:32:38] it'll make the H3C revert appear on top of the 19.01 article, but otherwise it'd be fine [09:29:27] *** Joins: travis-ci (~travis-ci@ec2-18-215-145-209.compute-1.amazonaws.com) [09:29:28] (spdk/master) nvmf/tcp: Rename nvme_tcp_qpair to spdk_nvmf_tcp_qpair (Ben Walker) [09:29:28] Diff URL: https://github.com/spdk/spdk/compare/7aeaa880b1de...2b59852b65bd [09:29:28] *** Parts: travis-ci (~travis-ci@ec2-18-215-145-209.compute-1.amazonaws.com) () [10:06:46] bwalker: a few data points on that bdevperf microbenchmark [10:07:12] we have an extra spdk_get_ticks() in the main path now - we still have the one in the reactor code, plus the one we added in spdk_thread_poll [10:07:36] but once we remove the stats from the reactor to the thread, we should be able to remove that one [10:08:30] bdev.c is inserting freed IOs into the cache at the TAIL, but removing them from the HEAD [10:09:09] that was there in 18.10 though, but it's still a nice optimization (I also get much more even performance across the reactors with this) [10:10:12] consider using read instead of randread for the benchmark - for randread there's an unavoidable div operation to transform the rand_r result into an offset into the block device [10:23:47] darsto/sethhowe: I think I fixed the repositories [10:24:02] we'll see if the sync starts working, but master is in the same place [10:24:10] also darsto you now have force push permission on spdk.github.io [10:24:22] I didn't have it either - but I did have administrator rights to grant that permission [10:25:07] jimharris: I have a patch locally that moves the stats over, so I'll get that pushed out and see what it does to the performance [10:25:32] there are some users of the spdk_event_call that need to be moved to spdk_thread_send_msg still [10:25:47] a few places in iSCSI and more in vhost [10:26:56] yeah all the hard ones [10:27:20] nah - I think the iSCSI ones are easy [10:27:24] not sure about vhost though [10:28:27] some of the challenge is that last I looked at these (1+ years ago probably), a lot of the concepts in iSCSI and vhost were still tied to cores [10:28:29] instead of threads [10:28:33] but I feel like that has been changing [10:30:31] found another simple fix - _spdk_bdev_io_submit wasn't getting inlined in the main I/O path - probably because it's used as a function pointer in at least one place [10:31:02] marking it explicitly inline worked and improved the microbenchmark by 8% on my E5v3 system [10:31:09] wow [10:31:19] I need to investigate re-packing spdk_bdev_io [10:31:26] see if there is anything clever we can do there [10:33:55] SLIST is quite a bit faster than TAILQ btw [10:34:05] according to that microbenchmark [10:55:49] *** Quits: davidsha (davidsha@nat/intel/x-msqpracmnrtecnze) (Ping timeout: 246 seconds) [11:16:55] *** Joins: travis-ci (~travis-ci@ec2-54-198-30-24.compute-1.amazonaws.com) [11:16:56] (spdk/master) nvmf: Collapse request.c into ctrlr.c (Ben Walker) [11:16:57] Diff URL: https://github.com/spdk/spdk/compare/2b59852b65bd...a4d666fd7a80 [11:16:57] *** Parts: travis-ci (~travis-ci@ec2-54-198-30-24.compute-1.amazonaws.com) () [11:22:04] *** Joins: travis-ci (~travis-ci@ec2-35-175-221-152.compute-1.amazonaws.com) [11:22:05] (spdk/master) vhost-scsi: use first free SCSI target ID if -1 specified (Pawel Wodkowski) [11:22:05] Diff URL: https://github.com/spdk/spdk/compare/4e614b3127c3...48834f0daade [11:22:05] *** Parts: travis-ci (~travis-ci@ec2-35-175-221-152.compute-1.amazonaws.com) () [11:26:18] *** Joins: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) [11:26:19] (spdk/master) nvmf/rdma: Eliminate management channel (Ben Walker) [11:26:20] Diff URL: https://github.com/spdk/spdk/compare/48834f0daade...608d80a033f2 [11:26:20] *** Parts: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) () [12:19:14] *** Joins: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) [12:19:14] (spdk/master) util: Move architecture detection to crc32c.c (Ben Walker) [12:19:15] Diff URL: https://github.com/spdk/spdk/compare/608d80a033f2...99382d2f7fe5 [12:19:15] *** Parts: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) () [12:20:04] *** Joins: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) [12:20:05] (spdk/master) nvmf/rdma: Remove stray spdk_nvmf_rdma_wr (Ben Walker) [12:20:05] Diff URL: https://github.com/spdk/spdk/compare/99382d2f7fe5...9521d11bdb31 [12:20:05] *** Parts: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) () [12:22:04] *** Joins: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) [12:22:04] (spdk/master) nvmf: Clarify wording of buf cache size parameter (Ben Walker) [12:22:05] Diff URL: https://github.com/spdk/spdk/compare/9521d11bdb31...ad272579b90a [12:22:05] *** Parts: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) () [12:26:09] *** Joins: travis-ci (~travis-ci@ec2-54-204-213-125.compute-1.amazonaws.com) [12:26:10] (spdk/master) autotest: introduce SPDK_RUN_FUNCTIONAL_TEST (Darek Stojaczyk) [12:26:10] Diff URL: https://github.com/spdk/spdk/compare/ad272579b90a...8604e568cb22 [12:26:10] *** Parts: travis-ci (~travis-ci@ec2-54-204-213-125.compute-1.amazonaws.com) () [12:27:25] *** Joins: travis-ci (~travis-ci@ec2-54-163-165-134.compute-1.amazonaws.com) [12:27:26] (spdk/master) bdev/ftl: Improved ftl_bdev rpc error responses (Wojciech Malikowski) [12:27:27] Diff URL: https://github.com/spdk/spdk/compare/8604e568cb22...b2402ec51636 [12:27:27] *** Parts: travis-ci (~travis-ci@ec2-54-163-165-134.compute-1.amazonaws.com) () [12:28:04] bwalker or sethhowe: could one of you validate (or refute) my concerns on https://review.gerrithub.io/c/spdk/spdk/+/441110? [12:28:37] *** Joins: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) [12:28:38] (spdk/master) reduce: fix ordering bug (paul luse) [12:28:38] Diff URL: https://github.com/spdk/spdk/compare/b2402ec51636...5abe0ec85224 [12:28:38] *** Parts: travis-ci (~travis-ci@ec2-54-158-99-99.compute-1.amazonaws.com) () [12:35:12] *** Joins: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) [12:35:13] (spdk/master) vhost: expose vdevs to the public API (Darek Stojaczyk) [12:35:14] Diff URL: https://github.com/spdk/spdk/compare/5abe0ec85224...08de94d0ddec [12:35:14] *** Parts: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) () [12:36:08] jimharris: done. You're right. [12:37:57] I'm not actually sure there are any cases where cmd or recv can be null if req is not null and the qpair is not in the state RDMA_REQUEST_STATE_FREE [12:38:06] so I think it might be a bogus check being added [12:38:15] if it's happening, it's surely just a bug [13:30:06] I did a pull and noted the new tag v19.01, but curiously (to me) there is no v19.01.x branch. Is that forthcoming, or has there been a change in the release/branch strategy (e.g. instantiate only if/when there's a point release)? [13:30:28] we make the v19.01.x branch when we need it [13:30:32] starts at where the tag is [13:30:47] we haven't gotten ourselves organized around a 19.01.1 release yet, so haven't made it just yet [13:31:06] still in that post-release giant merge of everything that was waiting window [13:31:37] bwalker: Thx. [13:57:23] *** Joins: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) [13:57:24] (spdk/master) bdev/ftl: no need to alloc buf when get geo from ssd (wuzhouhui) [13:57:25] Diff URL: https://github.com/spdk/spdk/compare/c778e3e54f17...4ee969c2cffc [13:57:25] *** Parts: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) () [14:28:21] Hi all, uname -i, according to the documentation is "not portable even across linux distributions" and in my case -i prints GenuineIntel and thus ./configure disables ISAL. When using -m i get the right output. Anyone else with this issue? [14:37:28] i don't but looks like it's something that needs to be fixed [14:37:37] what distro are you using out of curiousity? [14:38:38] and would you mind filing a bug in github for this? we'll likely want to merge this to a v19.01.x branch for a 19.01.1 release later this month [14:46:12] @jimharris im using gentoo -- and sure i can file a bug. [14:47:10] you could even push a patch to change it if you're so inclined [14:48:27] Yeah i should do that actually, as there are some other changes I would like to propose in the near future so this might a good maiden experience with gerrithub [14:49:47] excellent! [14:50:05] once you post the patch, i'll give you permissions in the spdk github project to have bugs assigned to you [14:50:28] then i can assign that bug to you [14:50:55] so first step is create issue in github right? [14:51:24] yes [14:51:42] then i'll see the issue and your github handle and will give you permissions [15:02:32] https://github.com/spdk/spdk/issues/648 [15:05:17] I *think* i'm registered to gerrithub as well... [15:11:31] i've assigned the bug to you [15:14:56] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [15:15:38] ok... its running the pre-commit hooks now, lets see what happens :) [15:27:40] It looks like it worked: https://review.gerrithub.io/c/spdk/spdk/+/443315 [15:30:11] now we'll wait for it to run through the Jenkins test pool [15:31:32] Ok [15:33:48] Let's say I have a suggestion to make a change, but it's not a bug. Should I then also file a github issue first? [15:34:43] your best bet would be to first bring it up here on IRC or on the SPDK mailing list for discussion [15:35:00] and then enhancements are typically tracked via Trello [15:36:00] Ok understood. [15:38:00] jimharris, gila FYI I updated the commit message before Jim's suggestion, should be close enough now I think maybe take another look? [15:38:35] Github is pretty picky about the format of the issue number - I think it has to be something like "Fixes #648". [15:39:11] LOL, I just updated that :) [15:39:21] so gila - we can fix up the commit message for you, or if you'd like to get experience with updating a patch and pushing a new version let us know [15:39:45] gila, FYI you can update your commit message from GerritHub too, no need to got a git amend/push if that's the only change [15:40:33] @peluse Ok see what you did, let me give at a shot. [15:40:48] rock on [15:41:59] o you beat me to it =) This looks fine thanks @peluse [15:43:00] you bet! I just noticed our dev page doesn't mention the "Fixes #" thing for github issues, will add that to the bullet on commit msgs [20:05:33] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 256 seconds) [20:15:52] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [23:54:14] *** Joins: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) [23:54:15] (spdk/master) thread: Keep caches of message objects on the thread object. (Ben Walker) [23:54:15] Diff URL: https://github.com/spdk/spdk/compare/c8d956fdeeb6...2446c5c6f3f4 [23:54:15] *** Parts: travis-ci (~travis-ci@ec2-54-145-168-192.compute-1.amazonaws.com) ()