[02:12:56] *** Joins: cgirish (ca037904@gateway/web/freenode/ip.202.3.121.4) [03:39:09] *** Quits: cgirish (ca037904@gateway/web/freenode/ip.202.3.121.4) (Ping timeout: 260 seconds) [05:55:27] *** Joins: Tomasz (~tzawadzk@192.55.54.45) [05:56:53] *** Joins: tomzawadzki (~tzawadzk@192.55.54.45) [05:57:17] *** Quits: Tomasz (~tzawadzk@192.55.54.45) (Client Quit) [06:00:48] *** Joins: Tomasz (~tzawadzk@192.55.54.45) [06:00:48] *** Quits: Tomasz (~tzawadzk@192.55.54.45) (Client Quit) [06:01:20] *** Quits: tomzawadzki (~tzawadzk@192.55.54.45) (Client Quit) [06:01:32] *** Joins: tomzawadzki (tzawadzk@nat/intel/x-hfcbtxuzgtajjibx) [08:59:42] *** Joins: jstern_ (~jstern@134.134.139.74) [09:26:35] *** Quits: tomzawadzki (tzawadzk@nat/intel/x-hfcbtxuzgtajjibx) (Ping timeout: 240 seconds) [10:10:13] *** Joins: johnmeneghini (~johnmeneg@pool-173-76-8-123.bstnma.fios.verizon.net) [10:44:40] bwalker: can you check https://review.gerrithub.io/#/c/361817/ - adds build/ to dpdk gitignore [10:46:58] done [10:54:53] I rebased it so it can be merged separately [12:57:31] bwalker: your patch series up through "Remove per-channel priority" looks good - how do you want to handle the rocksdb breakage? [13:55:34] not sure how to approach that [13:55:41] because if we push a rocksdb change, then the other builds break [13:58:24] i was thinking about how freebsd handles this [13:59:08] they basically do something like bump a rev number so you can #defines like we do for evolving DPDK APIs [13:59:58] it's still a bit of chicken-and-egg though, unless you are willing to check in the rocksdb change separate from the spdk changes [14:00:21] yeah, we can definitely add a spdk/version.h to help with some of this - but I don't want to add a bunch of manual work to bump the rev for every change [14:00:49] I'll check in the rocksdb change separately, but then we have to immediately merge my series [14:00:51] freebsd doesn't bump it for every change - basically you bump it if you are changing part of an api [14:01:16] yeah - let's do the rocksdb change and then immediately commit everything up to and including removing the channel priority [14:01:46] do we want to make a rocksdb branch that works with the SPDK 17.03 release? [14:02:27] a little late now to update the readme, but we could update the release notes to point at it [14:02:28] probably [14:02:48] could we also modify the rocksdb test script to fetch a specific commit id or tag? [14:03:00] that could be a stopgap around this problem [14:03:44] bwalker could push the rocksdb change first, then he changes the commit id or tag in the rocksdb test script as part of his channel priority removal patch [14:04:18] yeah [14:50:13] bwalker, drv: question on the nvme-related bdev nomem patches - do i punt on reset handling for now? or hold off on submitting until we can handle per-channel handling for reset operations? [14:50:47] if it's the latter then we need to coalesce the unmap operations now as a stopgap for the intermittent rocksdb failures [14:51:12] I'd hold off because my patches are real close to going out [14:51:21] and coalesce anyway, because I think it will help with performance [14:55:51] https://review.gerrithub.io/#/c/362086/ [15:24:54] *** Joins: whitepa (~whitepa@2601:601:1200:f23b:510d:fd92:df29:a7ba) [15:53:04] *** Quits: jstern_ (~jstern@134.134.139.74) (Ping timeout: 246 seconds) [17:35:20] It appears the RockDB testbed doesn't have pep8 installed. [17:35:24] Checking for POSIX includes... OK [17:35:25] ./scripts/check_format.sh: line 76: hash: pep8: not found [17:35:25] + timing_exit check_format [17:36:06] See: https://ci.spdk.io/builds/review/b5074cb592326ceb2c396c69bae84824283e61a6.1495493591/wkb-fedora-04/ [18:22:31] *** Joins: ziyeyang_ (~ziyeyang@134.134.139.77) [19:39:21] *** Joins: tsuyoshi (b42b2067@gateway/web/freenode/ip.180.43.32.103) [22:03:14] *** Quits: johnmeneghini (~johnmeneg@pool-173-76-8-123.bstnma.fios.verizon.net) (Ping timeout: 246 seconds)